Re: Get stuck when dropping a subscription during synchronizing table

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Get stuck when dropping a subscription during synchronizing table
Date: 2017-06-03 16:53:51
Message-ID: 982ca927-cd8d-e201-bc85-dc6455b413c5@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/2/17 14:52, Peter Eisentraut wrote:
> On 5/24/17 15:14, Petr Jelinek wrote:
>> All the locking works just fine the way it is in master. The issue with
>> deadlock with apply comes from the wrong handling of the SIGTERM in the
>> apply (we didn't set InterruptPending). I changed the SIGTERM handler in
>> patch 0001 just to die which is actually the correct behavior for apply
>> workers. I also moved the connection cleanup code to the
>> before_shmem_exit callback (similar to walreceiver) and now that part
>> works correctly.
>
> I have committed this, in two separate parts. This should fix the
> originally reported issue.
>
> I will continue to work through your other patches. I notice there is
> still a bit of discussion about another patch, so please let me know if
> there is anything else I should be looking for.

I have committed the remaining two patches. I believe this fixes the
originally reported issue.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2017-06-03 20:19:08 Re: Create subscription with `create_slot=false` and incorrect slot name
Previous Message Andres Freund 2017-06-03 16:04:26 Re: COPY (query) TO ... doesn't allow parallelism