Re: Add PortalDrop in exec_execute_message

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add PortalDrop in exec_execute_message
Date: 2021-06-09 19:34:53
Message-ID: 202106091934.f6m5kvqizrg4@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-Jun-09, Tom Lane wrote:

> I wrote:
> > It turns out that the problem is specific to SELECT FOR UPDATE, and
> > it happens because nodeLockRows is not careful to shut down the
> > EvalPlanQual mechanism it uses before returning NULL at the end of
> > a scan. If EPQ has been fired, it'll be holding a tuple slot
> > referencing whatever tuple it was last asked about. The attached
> > trivial patch seems to take care of the issue nicely, while adding
> > little if any overhead. (A repeat call to EvalPlanQualEnd doesn't
> > do much.)

Thanks for researching that -- good find.

> BTW, to be clear: I think Alvaro's change is also necessary.
> If libpq is going to silently do something different in pipeline
> mode than it does in normal mode, it should strive to minimize
> the semantic difference. exec_simple_query includes a PortalDrop,
> so we'd best do the same in pipeline mode. But this LockRows
> misbehavior would be visible in other operating modes anyway.

Agreed. I'll get it pushed after the patch I'm currently looking at.

--
Álvaro Herrera 39°49'30"S 73°17'W

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2021-06-09 19:44:39 Re: unnesting multirange data types
Previous Message Jeff Davis 2021-06-09 19:31:28 Re: alter table set TABLE ACCESS METHOD