es_query_dsa is broken
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-11-29T12:30:48Z
Lists: pgsql-hackers
Attachments
- fix-es_query_dsa-v1.patch (application/octet-stream) patch v1
Hi hackers, While reviewing commit c6755e23 I realised that es_query_dsa is broken. It might have made some kind of sense as a name and a concept in an earlier version of the proposal to add a DSA area for parallel query's use, when the DSA area was going to be independent of parallel query DSM segments and could have been used for the whole query. But as it stands, each Gather [Merge] node has its own DSA area in its own DSM segment, and that needs to be the one available to the nodes of the child plan when executed in the leader process and it needs to be not available to any other nodes in the tree. It's OK for the workers to have just one es_query_dsa set up at the beginning and used for the whole lifetime of the executor, but it's not OK for the leader to install it and forget about it as it does now. The attached draft patch (for discussion only) shows one way to fix that: only install it for the duration of Gather[Merge]'s ExecProcNode(child), instead of doing it in ExecInitParallelPlan(). Also for the [Re]IntializeDSM invocations. This type of install-call-clear coding isn't ideal, but unfortunately the area doesn't exist until the first time through ExecGather runs, and we don't seem to have another suitable scope (ie some object easily accessible to all children of a given Gather) to put it in right now. Better ideas? -- Thomas Munro http://www.enterprisedb.com
Commits
-
Fix crashes on plans with multiple Gather (Merge) nodes.
- b70ea4c75e5f 10.2 landed
- fd7c0fa732d9 11.0 landed
-
Teach bitmap heap scan to cope with absence of a DSA.
- c6755e233be1 11.0 cited
-
Provide a DSA area for all parallel queries.
- e13029a5ce35 10.0 cited