On Fri, Feb 2, 2018 at 3:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> 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: > >> /* 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); > > I happened across this patch while preparing the release notes, and > I'm quite distressed by it, because it completely breaks the point > of what I'd done in commit d46633506 (to wit, to not just blindly > assume, nor just Assert, that shm_toc_lookup always succeeds). > Do you mind if I change that Assert to a run-time test?
Hrm, I guess I could have done something like shm_toc_lookup(pcxt->toc, PARALLEL_KEY_ERROR_QUEUE, (pcxt->nworkers == 0)). I don't mind much if you change it, but I will note that for the record, before d46633506, we had a theoretical source of bugs, whereas after that commit, we had a bug. 445dbd82a fixed that; if you change this around again, please take care not to make it buggy again. Otherwise, I'll be the one who is quite distressed. :-) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company