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
>