Re: Proper way to clean-up connection for reuse (`DISCARD ALL` and default role)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Logan MAUZAIZE <logan(dot)mauzaize(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proper way to clean-up connection for reuse (`DISCARD ALL` and default role)
Date: 2025-01-20 17:06:58
Message-ID: 3011088.1737392818@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Logan MAUZAIZE <logan(dot)mauzaize(at)gmail(dot)com> writes:
> 1. clarify if `DISCARD ALL` behavior is the expected one or is it a bug?

DISCARD ALL is documented to do SET SESSION AUTHORIZATION DEFAULT,
and for me it does that, that is "session_authorization" reverts to
the login role, "role" reverts to "none", and as a consequence
current_user becomes the login role. I'm bemused by your claim
that "reset role" can cause current_user to become something
other than the current session_authorization ... maybe you are
doing something strange with setting "role" as an ALTER USER SET
or ALTER DATABASE SET property? Your example seems to omit
necessary setup.

(If you are doing that, you probably need to be running the latest
minor releases to see the same behavior I'm seeing; the changes for
CVE-2024-10978 affected some behavior that's related to this.)

One thing that is not well documented is that RESET ALL doesn't
touch either "session_authorization" or "role". I suppose the
reasoning is that those things are session properties specified
by the SQL standard. It's a little weird, but it's stood for
many years and I doubt we'd consider changing it now.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-01-20 17:21:57 Re: Bypassing cursors in postgres_fdw to enable parallel plans
Previous Message Sami Imseih 2025-01-20 17:04:40 Re: POC: track vacuum/analyze cumulative time per relation