Re: [COMMITTERS] pgsql: Add support for coordinating record typmodsamong parallel worke
От | Thomas Munro |
---|---|
Тема | Re: [COMMITTERS] pgsql: Add support for coordinating record typmodsamong parallel worke |
Дата | |
Msg-id | CAEepm=0y78KA-UFVA=q8joA4m9tPre5y7VxMy2Jzigo+O6E6MA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Add support for coordinating record typmods among parallel worke (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql: Add support for coordinating record typmods among parallel worke
Re: [COMMITTERS] pgsql: Add support for coordinating record typmods among parallel worke |
Список | pgsql-committers |
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
Вложения
В списке pgsql-committers по дате отправления: