From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Nick Sayer <nsayer(at)quack(dot)kfu(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: pg_upgrade problems |
Date: | 2002-10-29 18:24:37 |
Message-ID: | 200210291824.g9TIOba11613@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
I thought we disabled pg_upgrade for 7.2.X because we found we had
problems, I think with dealing with the transaction log files.
---------------------------------------------------------------------------
Nick Sayer wrote:
> I just got done upgrading 2 databases from 7.1.x to 7.2.3. In both cases
> the procedure outlined in pg_upgrade.1 failed. In one case, the failure
> was catastrophic. In neither case was any data lost (because I backed up
> with pg_dumpall first), but in both cases it appears the failure was
> similar: Everything appeared to go fine until the first 'vacuum analyze'
> after the procedure was complete.
>
> In the catastrophic case, unfortunately, I don't have a lot of info. I
> just sort of told myself, "Oh well. Good thing I backed it up," did
> another initdb and restored the backup. This was the first case, and the
> first time I ever attempted a pg_upgrade.
>
> In the second case, I was a lot more careful. Even so, the first vacuum
> analyze failed, but the database seems to have recovered without
> incident. Here's what the log said:
>
> DEBUG: database system is ready
> DEBUG: --Relation pg_type--
> DEBUG: Pages 3: Changed 0, Empty 0; Tup 170: Vac 0, Keep 0, UnUsed 0.
> Total CPU 0.00s/0.00u sec elapsed 0.00 sec.
> DEBUG: Analyzing pg_type
> FATAL 2: open of /home/pgsql/data/pg_clog/0004 failed: No such file or
> directory
> DEBUG: server process (pid 57274) exited with exit code 2
> DEBUG: terminating any other active server processes
> DEBUG: all server processes terminated; reinitializing shared memory
> and semaphores
> DEBUG: database system was interrupted at 2002-10-29 06:19:28 PST
> DEBUG: checkpoint record is at 0/4E00093C
> DEBUG: redo record is at 0/4E00093C; undo record is at 0/0; shutdown TRUE
> DEBUG: next transaction id: 4488258; next oid: 16781
> DEBUG: database system was not properly shut down; automatic recovery
> in progress
> DEBUG: redo starts at 0/4E00097C
> DEBUG: clog file /home/pgsql/data/pg_clog/0004 doesn't exist, reading
> as zeroes
> DEBUG: ReadRecord: record with zero length at 0/4E000B34
> DEBUG: redo done at 0/4E000B10
> DEBUG: database system is ready
>
> At this point, re-performing 'vacuum analyze' succeeded. Poking around
> at the actual data shows no aparent data loss.
>
> 1. What happened?
>
> 2. Is this an expected side effect of pg_upgrade?
>
> 3. Am I correct in believing that no data was actually lost?
>
> 4. Did I forget to do something critical before the pg_upgrade -1?
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korobov | 2002-10-29 18:47:40 | postgres xlog crashes - recovery procedure |
Previous Message | Tom Lane | 2002-10-29 17:59:21 | Re: pg_log: no such file or directory |