Re: Explain buffers wrong counter with parallel plans

On Wed, Aug 1, 2018 at 10:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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