"Chris Ochs" <[EMAIL PROTECTED]> writes:ERROR: invalid user ID: 194 PANIC: error during error recovery, giving up LOG: server process (PID 38302) was terminated by signal 6
Can you get a stack traceback from this crash? The only occurrence of "invalid user ID:" that I see in the source code is in GetUserNameFromId(), but there's no visible reason why that would be called during error recovery.
(gdb) bt #0 0x284f9dcf in kill () from /lib/libc.so.5 #1 0x284ee878 in raise () from /lib/libc.so.5 #2 0x28566f82 in abort () from /lib/libc.so.5 #3 0x08226a6a in errfinish () #4 0x08226953 in errfinish () #5 0x0822f54d in GetUserNameFromId () #6 0x081183a3 in show_session_authorization () #7 0x08232fe7 in show_all_settings () #8 0x0823196b in AtEOXact_GUC () #9 0x0823164f in AtEOXact_GUC () #10 0x08094cbd in XactPopRollback () #11 0x081a2334 in PostgresMain () #12 0x0817576b in PostmasterMain () #13 0x08174fa3 in PostmasterMain () #14 0x08173436 in PostmasterMain () #15 0x08172c1c in PostmasterMain () #16 0x0813b7fa in main () #17 0x0806d822 in _start () (gdb)
Also, a recipe for reproducing it would help. I spent a little time trying with your function with no success. You might be able to make it more reproducible by inserting delays in the setuser() function. (See the sleep() function in src/test/regress/sql/stats.sql for a quick and dirty way to delay.) I didn't have any luck, but since I don't know what's going on concurrently with this function in your environment, I was probably trying the wrong things.
I'm not sure myself exactly what the trigger is. The database connections are all through mod perl/Apache::DBI which I suspect have something to do with the problem. Maybe when a user is dropped, it changes the state of the database in some way that an active, open connection doesn't pick up? Just a guess. One thing I noticed is that the panic happens not when setuser is called on the user that is deleted, but on a user that doesn't, and never did, exist. It also keeps panicing on the same user even though I am calling setuser on several other users that don't exist (or did and have been deleted). It does appear though that deleting a user/schema has some sort of effect, because it always seems to happen when I have deleted a user/schema. In other words it's never happened in the absence of a recently deleted user that setuser was called on, even though it's not that user that it appears to panic on. If that makes sense....
Chris
regards, tom lane
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
