From: | "G(dot) Anthony Reina" <reina(at)nsi(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Fwd: Weird backup file] |
Date: | 2000-11-21 01:04:29 |
Message-ID: | 3A19CA1D.27B6DAEC@nsi.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Your procedure was fine, but ALTER TABLE RENAME was mighty flaky in
> pre-7.0 releases. Even in 7.0, doing it inside a transaction block is
> asking for trouble (that's finally fixed for 7.1, thank goodness).
> I suspect you got bit by an ALTER bug. I'm not sure about the exact
> mechanism, but I have a suspicion: it looks a lot like some blocks
> of the original ellipse_cell_proc table got written into the new table.
> I know 6.5 failed to clear old shared disk buffers during a table
> rename. I can't recall if it was sloppy about that during a table drop
> as well, but it would've taken both bugs to cause this result if I'm
> guessing right that that was the failure path.
>
> There are good reasons why we've been urging people to update to 7.0.*
> ASAP ... I'm afraid you got bit by one :-(. Sorry about that.
>
>
Okay. At least the problem has been solved. It seems though that the last 2
times I've done a backup (in order to upgrade to the latest Postgres version)
I've had data lost because of some error. I'm getting a little concerned
about the quality of the Postgres backups.
-Tony
>
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2000-11-21 01:26:29 | RE: Table/Column Constraints |
Previous Message | Don Baccus | 2000-11-21 00:45:21 | Re: PG 7.1 pre-beta bug ... |