Re: 7.4.3 server panic

> "Chris Ochs" <chris@paymentonline.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
>
>