Re: PG_CATCH used without PG_RETHROW - Mailing list pgsql-hackers

From 正华吕
Subject Re: PG_CATCH used without PG_RETHROW
Date
Msg-id CANerzAd_S-yQ+L3e8hPp+as7eJWoTJ9sXw0jbV5AKTarrz0igg@mail.gmail.com
Whole thread Raw
In response to Re: PG_CATCH used without PG_RETHROW  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi, I think this is a bug because this function's CATCH clause does not
restore memroycontext. Thus when leaving the function, the CurrentMemroyContext
will be ErrorMemroyContext.

I see this part of code is refactored in master branch, but in REL_16_STABLE, the code
is still there.

The following SQL might lead to PANIC (reference to memory that just reset)

zlyu=# select version();
                                                   version
-------------------------------------------------------------------------------------------------------------
 PostgreSQL 15.3 on aarch64-unknown-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
(1 row)

zlyu=# select xml_is_well_formed('<a>') or
       array_length(array_append(array[random(), random()], case when xml_is_well_formed('<a>') then random() else random() end), 1) > 1;
ERROR:  cache lookup failed for type 2139062143
zlyu=#



Simple fix is to backport the change from master branch or restore the context.

Tom Lane <tgl@sss.pgh.pa.us> 于2023年8月2日周三 16:32写道:
Greg Stark <stark@mit.edu> writes:
> My understanding is that PG_TRY/PG_CATCH doesn't save enough state to
> avoid rethrowing errors and if you want to actually continue the
> transaction you must use a subtransaction. As a result I was under the
> impression it was mandatory to PG_RETHROW as a result.

> If that's the case then I think I just came across a bug in
> utils/adt/xml.c where there's no PG_RETHROW:

The reason we think that's OK is that we assume libxml2 does not call back
into the general backend code, so there is no PG state we'd have to undo.

                        regards, tom lane


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Next
From: Bharath Rupireddy
Date:
Subject: Re: Adding a LogicalRepWorker type field