-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Tom Lane
Sent: 05 July 2007 19:17
To: Alvaro Herrera
Cc: James Wilford; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] More than one pg_database entry for database
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> As far as getting out of the situation, the only really good answer
>> is a dump and reload. I can't think of any simple way of getting rid
>> of the bogus row, but what you should be able to do to let pg_dump
>> work is to rename misp to something else. You can rename it back
>> after getting through the dump/reload, of course.
> Or roll the XID counter back, vacuum the table, and restore the XID to
> the original value. This is done with pg_resetxlog, though I am not
> sure if we shipped it in 7.3.
That seems fairly hazardous, in particular there might be undesirable
side-effects on other system catalogs while you are running with the
set-back XID counter.
Also, I see no very good reason to assume that this is the only
wraparound problem present in the DB. A dump and reload would probably
be useful to help check for other inconsistencies.
regards, tom lane
I'd like to try the dump and reload - the only problem is that I can't
use pg_dump because of the error. And I can't rename the entry in
pg_database because my update statement won't match any rows.
I'm going to set up a test box with the same OS/PG version and try
copying the raw data across from the data directory. It looks like the
only option at the moment. And then I'll definitely upgrade!
Thanks,
James