Horton

Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>, "Adam, Etienne (Nokia-TECH/Issy Les Moulineaux)" <etienne.adam@nokia.com>, PostgreSQL Bugs <pgsql-bugs@postgresql.org>, "Duquesne, Pierre (Nokia-TECH/Issy Les Moulineaux)" <pierre.duquesne@nokia.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-28T13:04:40Z
Lists: pgsql-bugs, pgsql-hackers 
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Mon, Aug 28, 2017 at 6:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Um, what's different about that than before?

> Earlier, we perform the rescan of all the nodes before ExecProcNode,
> so workers will always start (restart) after the scan descriptor is
> initialized.

If what you're complaining about is that I put back the "if
(outerPlan->chgParam == NULL)" test to allow postponement of the
recursive ExecReScan call, I'm afraid that it's mere wishful
thinking that omitting that test in nodeGather did anything.
The nodes underneath the Gather are likely to do the same thing,
so that the parallel table scan node itself is going to get a
postponed rescan call anyway.  See e.g. ExecReScanNestLoop().

I see your point that there's inadequate interlocking between resetting
the parallel scan's shared state and starting a fresh set of workers,
but that's a pre-existing bug.  In practice I doubt it makes any
difference, because according to my testing the leader will generally
reach the table scan long before any workers do.  It'd be nice to do
better though.

I'm inclined to think that what's needed is to move the reset of the
shared state into a new "ExecParallelReInitializeDSM" plan tree walk,
which would have to occur before we start the new set of workers.

			regards, tom lane

Commits

  1. Separate reinitialization of shared parallel-scan state from ExecReScan.

  2. Restore test case from a2b70c89ca1a5fcf6181d3c777d82e7b83d2de1b.

  3. Force rescanning of parallel-aware scan nodes below a Gather[Merge].

  4. Fix ExecReScanGatherMerge.

  5. Add missing call to ExecReScanGatherMerge.