Strange problem when upgrading to 7.2 with pg_upgrade. 
Author Message
 Strange problem when upgrading to 7.2 with pg_upgrade.

This is a good bug report.  I can fix pg_upgrade by adding clog files
containing zeros to pad out to the proper length.  However, my guess is
that most people have already upgrade to 7.2.X, so there isn't much
value in fixing it now.  I have updated pg_upgrade CVS for 7.3, and
hopefully we will have it working and well tested by the time 7.3 is
released.

Compressed clog was new in 7.2, so I guess it is no surprise I missed
that change in pg_upgrade.  In 7.3, pg_clog will be moved over from the
old install, so this shouldn't be a problem with 7.3.

Thanks for the report.  Sorry I don't have a fix.

---------------------------------------------------------------------------

Quote:

> I've started playing around with 7.2 on one of my development machines.
> I decided to try the pg_upgrade program, something I usually never do.

> Anyway, I followed the steps in the pg_upgrade (going from 7.1.3 to
> 7.2), and then when I started the database up after the upgrade finished
> and vacuumed one of my tables, i get these error messages from the
> postmaster.  After this point I cannot restart the postmaster without
> resetting the xlog.

> I've kept the PGDATA directory around incase someone thinks this is
> worth looking into, i would be more than happy to help out.

> If i migrate the data over manually like a always do (pg_dump then
> pg_restore), i don't have any problems.  Part of the problem might be
> path names for shared libraries specified in CREATE FUNCTION; I started
> using pg back when it was version 6 before '$libdir' was supported and I
> haven't bothered to take the absolute path names out yet -- i've just
> updated it with each release (each release is installed in a different
> location in case i need to roll back, and so i can test multiple version
> at one time).  not sure if pg_upgrade even checks for this.


> 256 -D/mo
> DEBUG:  database system was shut down at 2002-02-14 12:20:53 MST
> DEBUG:  checkpoint record is at 1/A7000010
> DEBUG:  redo record is at 1/A7000010; undo record is at 1/A7000010;
> shutdown TRUE
> DEBUG:  next transaction id: 589031; next oid: 19512
> DEBUG:  database system is ready

> DEBUG:  --Relation developer--
> DEBUG:  Pages 669: Changed 0, Empty 0; Tup 51508: Vac 0, Keep 0, UnUsed
> 0.
>    Total CPU 0.07s/0.03u sec elapsed 0.11 sec.
> DEBUG:  Analyzing developer
> FATAL 2:  read of clog file 0, offset 139264 failed: Success
> DEBUG:  server process (pid 17786) exited with exit code 2
> DEBUG:  terminating any other active server processes
> NOTICE:  Message from PostgreSQL backend:
>    The Postmaster has informed me that some other backend
>    died abnormally and possibly corrupted shared memory.
>    I have rolled back the current transaction and am
>    going to terminate your database system connection and exit.
>    Please reconnect to the database system and repeat your query.
> DEBUG:  all server processes terminated; reinitializing shared memory
> and semaphores
> DEBUG:  database system was interrupted at 2002-02-14 12:20:58 MST
> DEBUG:  checkpoint record is at 1/A7000010
> DEBUG:  redo record is at 1/A7000010; undo record is at 1/A7000010;
> shutdown TRUE
> DEBUG:  next transaction id: 589031; next oid: 19512
> DEBUG:  database system was not properly shut down; automatic recovery
> in progress
> DEBUG:  redo starts at 1/A7000050
> FATAL 2:  read of clog file 0, offset 139264 failed: Success
> DEBUG:  startup process (pid 17788) exited with exit code 2
> DEBUG:  aborting startup due to startup process failure




> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/hda8               248895    192496     43549  82% /
> /dev/hda1                31079      4988     24487  17% /boot
> /dev/hda5             24080660   6601476  17479184  28% /home
> /dev/hda6              5044156   1930892   2857032  41% /usr
> /dev/hda9               248895    133875    102170  57% /var
> /dev/hdd1             59919196  39090008  20829188  66% /disk

> 256 -D/mo
> DEBUG:  database system was interrupted being in recovery at 2002-02-14
> 12:21:06 MST
>    This probably means that some data blocks are corrupted
>    and you will have to use the last backup for recovery.
> DEBUG:  checkpoint record is at 1/A7000010
> DEBUG:  redo record is at 1/A7000010; undo record is at 1/A7000010;
> shutdown TRUE
> DEBUG:  next transaction id: 589031; next oid: 19512
> DEBUG:  database system was not properly shut down; automatic recovery
> in progress
> DEBUG:  redo starts at 1/A7000050
> FATAL 2:  read of clog file 0, offset 139264 failed: Success
> DEBUG:  startup process (pid 17793) exited with exit code 2
> DEBUG:  aborting startup due to startup process failure

> ---------------------------(end of broadcast)---------------------------


--
  Bruce Momjian                        |   http://www.***.com/

  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------



Sun, 26 Sep 2004 02:29:23 GMT
 Strange problem when upgrading to 7.2 with pg_upgrade.

I wouldn't be so quick to assume that almost everyone has upgraded by now.  I
know we have not, at least not in production.


Quote:
> This is a good bug report.  I can fix pg_upgrade by adding clog files
> containing zeros to pad out to the proper length.  However, my guess is
> that most people have already upgrade to 7.2.X, so there isn't much
> value in fixing it now.  I have updated pg_upgrade CVS for 7.3, and
> hopefully we will have it working and well tested by the time 7.3 is
> released.

> Compressed clog was new in 7.2, so I guess it is no surprise I missed
> that change in pg_upgrade.  In 7.3, pg_clog will be moved over from the
> old install, so this shouldn't be a problem with 7.3.

> Thanks for the report.  Sorry I don't have a fix.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly


Sun, 26 Sep 2004 03:37:57 GMT
 Strange problem when upgrading to 7.2 with pg_upgrade.

Quote:
> I wouldn't be so quick to assume that almost everyone has upgraded by now.  I
> know we have not, at least not in production.

yeah, what he said.  Test, QA and development yes, production, no.

-Brad

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Sun, 26 Sep 2004 07:26:41 GMT
 Strange problem when upgrading to 7.2 with pg_upgrade.

Quote:


> > I wouldn't be so quick to assume that almost everyone has upgraded by now.  I
> > know we have not, at least not in production.

> yeah, what he said.  Test, QA and development yes, production, no.

The question is anyone who has delayed installing 7.2 will be using
pg_upgrade.  Odds are they will not, and clearly we can't get enough
testing on pg_upgrade to be sure it will work well with 7.2.X.

--
  Bruce Momjian                        |  http://candle.pha.pa.us

  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Sun, 26 Sep 2004 08:11:40 GMT
 
 [ 4 post ] 

 Relevant Pages 

1. Strange problem when upgrading to 7.2 with pg_upgrade.

2. 7.2 to 7.3 upgrade data dictionary problems

3. Problems with upgrading 7.1.3 -> 7.2

4. 7.2 Upgrade problems: Cannot restore from pg_dumpall

5. pgsql/contrib/pg_upgrade README pg_upgrade

6. pgsql/contrib/pg_upgrade README pg_upgrade

7. pgsql/contrib/pg_upgrade pg_upgrade

8. pgsql/contrib/pg_upgrade README pg_upgrade pg_ ...

9. pgsql-server/ ontrib/pg_upgrade/pg_upgrade oc/ ...

10. pgsql/contrib/pg_upgrade pg_upgrade

11. pgsql/ /HISTORY ontrib/pg_upgrade/pg_upgrade.1 ...

12. Strange output in Journal in DB2 7.2 UDB on W2k


 
Powered by phpBB® Forum Software