Re: Add PortalDrop in exec_execute_message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
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:07:48
Message-ID: 1428037.1623265668@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.)

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-06-09 19:15:37 Re: Estimating HugePages Requirements?
Previous Message Magnus Hagander 2021-06-09 19:07:09 Re: Estimating HugePages Requirements?