Re: [Fwd: Weird backup file]

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

>

In response to

Browse pgsql-hackers by date

  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 ...