On Fri, Sep 15, 2017 at 4:59 PM, Tom Lane <tgl@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
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
