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
