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
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? |