Re: plpgsq_plugin's stmt_end() is not called when an error is caught

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pavel(dot)stehule(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: plpgsq_plugin's stmt_end() is not called when an error is caught
Date: 2022-12-15 15:49:39
Message-ID: 3371138.1671119379@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> writes:
> I don't think we need additional PG_TRY() for that since exec_stmts()
> is already called in PG_TRY() if there is an exception block. I meant
> to call stmt_end() in PG_CATCH() in exec_stmt_block() (i.e. only when
> an error is caught by the exception block). Currently, if an error is
> caught, we call stmt_begin() and stmt_end() for statements executed
> inside the exception block but call only stmt_begin() for the
> statement that raised an error.

I fail to see anything wrong with that. We never completed execution
of the statement that raised an error, but calling stmt_end for it
would imply that we did. I think changing this will break more things
than it fixes, completely independently of whatever cost it would add.

Or in other words: the initial complaint describes a bug in pg_hint_plan,
not one in plpgsql.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2022-12-15 16:13:23 Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs)
Previous Message Matthias van de Meent 2022-12-15 14:50:19 Re: New strategies for freezing, advancing relfrozenxid early