Re: More than one pg_database entry for database

"James Wilford" <jwilford@mistral.net> writes:
> It's a redhat version of 7.3 - rh-postgresql-server-7.3.8-2 is the
> package.

That was obsoleted by Red Hat well over two years ago; you are overdue
for an update.

>    xmin   |    cmin    |    xmax    | cmax |   oid    |  ctid  | datname
> ----------+------------+------------+------+----------+--------+--------
>  59254726 |          0 |          0 |    0 | 31238435 | (0,28) | misp
>         2 | 2430588419 | 2430588419 |    0 |  6790290 | (0,37) | misp

It definitely looks to me like you have a problem with XID wraparound :-(
The (0,37) row was apparently deleted long ago, but never vacuumed away,
and now its xmax has wrapped around past the 2-billion-transaction event
horizon, causing it to appear visible to MVCC-using queries.  So there's
something broken about your routine vacuuming procedures; you'd better
take a look at that.

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.

            regards, tom lane