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
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
