Re: database corruption

From: Joe Conway <mail(at)joeconway(dot)com>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: database corruption
Date: 2003-08-30 20:16:42
Message-ID: 3F51062A.70106@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera wrote:
> On Sat, Aug 30, 2003 at 12:57:26PM -0700, Joe Conway wrote:
>
>>Joe Conway wrote:
>>
>>>I don't have any more detail yet on exactly what he was doing at this
>>>point, but I grabbed a copy of $PGDATA and looked at it on my own
>>>machine (since he doesn't have debug and assert support). Logging into
>>>any other database works fine, but the offending database produces this
>>>backtrace:
>>
>>It turns out the "corruption" was user error. He ran a statement that
>>inadvertantly set reltriggers = 1 for every row in pg_class. This is
>>what led to the infinite recursion.
>
> For the record, how were you able to detect this?

The backtrace from the core file showed that the recursion was going on
between RelationSysNameGetRelation(), relation_openr(), heap_openr(),
RelationBuildTriggers() and RelationBuildDesc(). It seemed odd that
pg_trigger seemed to be getting a trigger applied to it, so I guessed
that bypassing RelationBuildTriggers() for system tables would allow me
in to the database.

About the time I got in and started looking around, I finally got in
touch with the user, who confirmed he had been trying to disable then
re-enable triggers when the problem occurred. He ran a statement like:
update pg_class set reltriggers = 1;
thinking that reltriggers was a "flag" (0 == off, 1 == on). That's when
it all suddenly made sense to me ;-)

Fortunately this was his own development database he was messing with,
but it was an interesting exercise none-the-less. Maybe this reinforces
the need to have a command for enabling/disabling triggers. I vaguely
remember discussion about that -- did it make it into 7.4?

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Manfred Spraul 2003-08-30 20:18:16 Re: Linux2.6 overcommit behaviour
Previous Message Alvaro Herrera 2003-08-30 20:04:40 Re: database corruption