From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | 857348270(at)qq(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17837: The potential risks associated with executing "commit" in a procedure. |
Date: | 2023-03-13 20:23:31 |
Message-ID: | 2179740.1678739011@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> Recently, I have noticed that executing "commit" in a procedure calls
> PreCommit_Portals in the kernel, which sets the resowner of the top level
> portal to null. However, subsequent statements still use this portal, and
> its resowner remains null. Is there any risk associated with this or could
> it lead to unexpected behavior?
I do not see any reason to believe there's a bug here. After the
COMMIT, CurrentResourceOwner won't be pointing at the portal's
resowner anymore, but at a resowner belonging to the newly-started
transaction (cf AtStart_ResourceOwner). The portal's resowner would
only have been used for resources that went away at commit, so it's
not needed anymore. Nor is there any code that would try to
re-install that resowner as active.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-03-14 01:51:09 | BUG #17839: Heap-buffer overflow on float8_to_char with invalid template |
Previous Message | PG Bug reporting form | 2023-03-13 19:45:44 | BUG #17838: Uninstall of PostgreSQL 13.9.3 fails on Windows 11 |