>
> > (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 ()
>
> The trace is a bit bogus, but it did help me figure out what's going on:
> I think that we're trying to report the current session authorization to
> the client (which is something that happens automatically on any change)
> and it's referencing a deleted user. Is it possible that your setup is
> deleting the user that the entire session is running as?
>
> regards, tom lane
By entire session do you mean the superuser that initially makes the
connection? If so, then definitely no that user is not deleted. It's
possible that a set session authorization was issued, the current session
user was then deleted by another connection, and then the session of the
deleted user tried to report. I am calling reset session authorization at
the start of every run of our application, but I could have missed something
so that it does end up in a state of trying to report on a user session
where the user no longer exists.
Chris
