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