On Fri, Sep 15, 2017 at 4:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Looks like force_parallel_mode might be the key to causing that.
Yeah. The regress tests in d36f7efb39e1b9613193b2e12717dbe2418ddae5 tested this stuff in parallel mode, but only a happy case to demonstrate blessed RECORD types travelling through tqueue.c correctly before and after ripping out the remapping stuff. The problem here was that I do some cleanup in the DSM detach hook of the new session segment, and that involved reading data that could point to another segment (if the DSA area needed more space). That can blow up if that other segment happens to have been unmapped first in the arbitrary order of resource cleanup in an aborting worker. I do have some thoughts on how to solve that general problem, but in this case it's completely unnecessary anyway. The attached patch fixes the problem by getting rid of the code that accesses shmem in the detach hook. With this patch applied installcheck survives on a cluster with force_parallel_worker=regress. -- Thomas Munro http://www.enterprisedb.com
0001-Fix-crash-in-shared_record_typmod_registry_worker_de.patch
Description: Binary data
-- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
