I have to agree that it was pilot error, but I can't for the life of me
understand how 1/4 of the tables went into the right db and the others
into template1. I saved changed data, droped the hmzbook db, recreated
it and ran psql -U hmz -f db.hmzbook and it put all the tables into
hmzbook as it should have and template1 remained clean. If the
db.hmzbook had more than one \connect in it or something, I wouldn't
hesitate to have considered password/pilot error.
It's never happened before and postgres is one of the most stable
software packages I have ever used. As to your questions, yes the data
was found as expected and table dumps were clean. In my opinion, this
has to be marked up to pilot error as the most reasonable answer with
some as yet unknown reason for the split in tables. Perhaps the socket
blew up and psql reconnected to template1?
David
Tom Lane wrote:
>David Ford <david+cert@blue-labs.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
>
>