BUG #17837: The potential risks associated with executing "commit" in a procedure.

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: 857348270(at)qq(dot)com
Subject: BUG #17837: The potential risks associated with executing "commit" in a procedure.
Date: 2023-03-13 12:40:11
Message-ID: 17837-9e65be9846767162@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 17837
Logged by: Andre Lin
Email address: 857348270(at)qq(dot)com
PostgreSQL version: 12.14
Operating system: Linux x86_64 GNU/Linux
Description:

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? If this is expected, how should I interpret
(or ... understand) portal->resowner? I would greatly appreciate your
guidance on this matter.

For example:

create or replace procedure p ()
as
$$
declare
vsql varchar := 'aa';
begin
for i in 1..10
loop
raise notice '%',i;
end loop;
commit;
for i in 1..10
loop
raise notice '%',i;
end loop;
commit;
end;
$$
language plpgsql;

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-03-13 15:26:14 Re: BUG #17835: Two assertions failed in nodeAgg.c and execExprInterp.c with the same SQL
Previous Message Dean Rasheed 2023-03-13 11:46:45 Re: BUG #17792: MERGE uses uninitialized pointer and crashes when target tuple is updated concurrently