Re: Explain buffers wrong counter with parallel plans - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Explain buffers wrong counter with parallel plans
Date
Msg-id CA+TgmobHRUXoP4g5PgR6HLOpFx3NMMJyprKa08nooj3Xgui1Vg@mail.gmail.com
Whole thread Raw
In response to Re: Explain buffers wrong counter with parallel plans  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Explain buffers wrong counter with parallel plans
List pgsql-hackers
On Wed, Aug 1, 2018 at 10:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> ... But scanning backwards is
>> a problem.  I'm not exactly sure what the best way of handling that
>> is, but one thing I think might work is to save ExecutePlan's
>> execute_once flag in the EState and then make the call in nodeLimit.c
>> and the one in ExecutePlan itself conditional on that flag.  If we
>> know that the plan is only going to be executed once, then there can
>> never be any backward fetches and it's fine to shut down as soon as we
>> finish going forward.
>
> Shouldn't this be dealt with by a eflag bit passed down at executor
> init time?  What you're describing sounds a lot like somebody
> invented a different way because they were unfamiliar with eflags.

Uh, yeah, maybe.  I'm a bit unfamiliar with eflags.  :-)

Looking at it, this sounds suspiciously something where we could just
test EXEC_FLAG_BACKWARD, based on the comments for that flag, but I
wouldn't be willing to bet very much on me being right about that.
Can somebody try to fetch backward even if this flag wasn't provided?
If so, we need to make sure that the shutting down a node doesn't
leave it in a state where a fetch attempt will crash.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
Next
From: Dave Cramer
Date:
Subject: Re: patch to ensure logical decoding errors early