Re: 7.4.3 server panic

> "Chris Ochs" <chris(at)paymentonline(dot)com> 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
>
>