Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
We have very strange behavior from an internal production database.
There are multiple symptoms, all pointing to a problem with clusterwide
tables. For example:
"psql -l" really should produce the same results as doing "\l" in the
template1 database. Does it?
Sorry -- on my last post "psql -l" was pointing to the wrong place.
[EMAIL PROTECTED]:~> psql -p 5433 -l
List of databases
Name | Owner | Encoding
------+-------+----------
(0 rows)
[EMAIL PROTECTED]:~> psql -U postgres -p 5433 template1
Welcome to psql 7.4.8, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
template1=# \l
List of databases
Name | Owner | Encoding
------+-------+----------
(0 rows)
So they agree in template1 and cyspec databases.
If so, the next thing to look at is probably whether the pg_class and
pg_attribute entries for pg_database
look the same in template1 and in cyspec. Similarly you could compare
what pg_shadow looks like from different databases, and what the local
system tables have as entries for it.
Did that - they look the same. We did a simple
cat 1262 | less
to view the contents of pg_database and indeed the data looks to be
there. Similarly a simple cat of the pg_shadow relfilenode shows the
colprod user. Is it possible that we have corrupted shared memory, and a
database restart will fix the problem? We didn't want to restart until
the forensics were done.
Joe
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
