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
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 |