"Chris Ochs" <chris@paymentonline.com> writes:
>> 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?
> 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.
Okay. The ideal fix would be for the system to refuse to allow
dropping a user that someone is currently connected or authorized as,
but that seems impractical to enforce. (An authorization could, for
example, be hidden a few levels down a session's call stack if there
are nested SECURITY DEFINER function calls. It'd be expensive even
to check this for your own session, let alone any other sessions.)
What I think I will do is alter the SET SESSION AUTHORIZATION code so
that it stores both the name and userID of the currently authorized
user, and then it can just report the name part to the client without
having to do a lookup, which is a Good Thing if we're in an aborted
transaction.
The downside of this is that an ALTER USER RENAME won't affect the
stored data and so the reported authorization name won't change in
existing sessions ... but I don't think that works now anyway.
regards, tom lane
