Re: very concerning, tables hopped from one database to

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Ford <david+cert(at)blue-labs(dot)org>
Cc: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, thomas(at)fourpalms(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: very concerning, tables hopped from one database to
Date: 2002-04-22 00:40:13
Message-ID: 29609.1019436013@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

David Ford <david+cert(at)blue-labs(dot)org> writes:
> I'm not sure, but being that there was only one connect statement, and
> 1/4 of the tables were there, I have no idea what went wrong. I
> imported it by hand so I should have noticed if anything was amiss.

Do you find the expected data in the tables --- both the ones that
were where you expected, and the ones that were not? Do the tables
pg_dump cleanly in both cases?

If so, I've got to conclude it was some kind of pilot error. I can
imagine bugs that would cause rows to get copied from one database's
pg_class to another's (cf the aforementioned buffer management error).
But for a "clean" transfer you'd need that to happen simultaneously for
rows in pg_class, pg_attribute, and other places. And make the rows
disappear from the source database, which that old buffer bug did *not*
do. And cause the physical files holding the data to move from one
database's subdirectory to another. This is getting pretty far beyond
the bounds of credibility ...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message GB Clark 2002-04-22 01:34:06 Re: PostgreSQL - regularly sync.ing remote and local data
Previous Message David Ford 2002-04-22 00:31:38 Re: very concerning, tables hopped from one database to