On Tue, Nov 28, 2017 at 9:45 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>> I haven't checked whether this fixes the bug, but if it does, we can
>> avoid introducing an extra branch in BitmapHeapNext.
>
> With my test it's fixing the problem.
I tested it some more and found that, for me, it PARTIALLY fixes the
problem. I tested like this:
--- a/src/backend/access/transam/parallel.c
+++ b/src/backend/access/transam/parallel.c
@@ -279,7 +279,7 @@ InitializeParallelDSM(ParallelContext *pcxt) * parallelism than to fail outright. */
segsize= shm_toc_estimate(&pcxt->estimator);
- if (pcxt->nworkers > 0)
+ if (pcxt->nworkers > 0 && false) pcxt->seg = dsm_create(segsize, DSM_CREATE_NULL_IF_MAXSEGMENTS); if
(pcxt->seg!= NULL) pcxt->toc = shm_toc_create(PARALLEL_MAGIC,
That turned out to produce more than one problem. I find that the
select_parallel test then fails like this:
ERROR: could not find key 18446744073709486082 in shm TOC at 0x10be98040
The fix for that problem seems to be:
--- a/src/backend/access/transam/parallel.c
+++ b/src/backend/access/transam/parallel.c
@@ -430,7 +430,8 @@ ReinitializeParallelDSM(ParallelContext *pcxt)
/* Recreate error queues. */ error_queue_space =
- shm_toc_lookup(pcxt->toc, PARALLEL_KEY_ERROR_QUEUE, false);
+ shm_toc_lookup(pcxt->toc, PARALLEL_KEY_ERROR_QUEUE, true);
+ Assert(pcxt->nworkers == 0 || error_queue_space != NULL); for (i = 0; i < pcxt->nworkers; ++i) { char
*start;
With that fix in place, I then hit a crash in parallel bitmap heap
scan. After applying no-pstate.patch, which I just committed and
back-patched to v10, then things look OK. I'm going to apply the fix
for the error_queue_space problem also.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
