| 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: | Whole Thread | Raw Message | 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
| 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 |