Skip site navigation (1) Skip section navigation (2)

Re: strange behavior (corruption?) of large production

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: strange behavior (corruption?) of large production
Date: 2005-12-03 00:06:33
Message-ID: 4390E189.9040802@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> 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.

postgres(at)csdfds1:~> psql -p 5433 -l
     List of databases
  Name | Owner | Encoding
------+-------+----------
(0 rows)

postgres(at)csdfds1:~> 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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-12-03 00:11:28
Subject: Re: strange behavior (corruption?) of large production database
Previous:From: Marc G. FournierDate: 2005-12-03 00:03:44
Subject: Re: Spam 508

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group