Re: Dropping a database that does not exist - Mailing list pgsql-general

From Tom Lane
Subject Re: Dropping a database that does not exist
Date
Msg-id 28447.1139842257@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dropping a database that does not exist  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: Dropping a database that does not exist  (Tham Shiming <shiming@misatravel.com>)
List pgsql-general
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> Tham Shiming <shiming@misatravel.com> writes:
>>> OK, checking pg_shadow, the usesysid for each entry is unique.
>>> pg_database, however, showed the duplicate databases. A
>>> short sample output from pgAdmin.
>>>
>>> datname    datdba
>>> db1        101
>>> db1        101
>>> db2        102
>>> db3        103
>>> db3        103
>>
>> Does anyone know what the underlying query is that pgadmin uses for
>> this display?

> pgAdmin wouldn't display anything like that unless the user entered the
> query themselves, or did a 'view data' on pg_database (in which case it
> would just be a select *, possibly with a user entered WHERE restriction
> or an ORDER BY).

Hmm.  If it's not a join, the only explanation that comes to mind for
phantom rows is transaction ID wraparound.  Could we see the output of

    select ctid, xmin, xmax, datname from pg_database;


            regards, tom lane

pgsql-general by date:

Previous
From: "Dave Page"
Date:
Subject: Re: Dropping a database that does not exist
Next
From: "Ken Winter"
Date:
Subject: Re: Why does an ON SELECT rule have to be named "_RETURN"?