On 13/06/17 18:33, Masahiko Sawada wrote:
> On Wed, Jun 14, 2017 at 1:02 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> On Tue, Jun 13, 2017 at 4:53 PM, Petr Jelinek
>> <petr.jelinek@2ndquadrant.com> wrote:
>>> On 13/06/17 09:06, Masahiko Sawada wrote:
>>>> Hi,
>>>>
>>>> The commit ddd7b22b225ae41d16ceb218b387645cb9becfdc makes table sync
>>>> workers stop when subscription relation entry is removed. It doesn't
>>>> work fine inside transaction block. I think we should disallow to use
>>>> the following subscription DDLs inside a transaction block. Attached
>>>> patch.
>>>>
>>>
>>> Can you be more specific than "It doesn't work fine inside transaction
>>> block", what do you expect to happen and what actually happens?
>>>
>>
>> If we do ALTER SUBSCRIPTION SET PUBLICATION during executing table
>> sync then it forcibly stops concurrently running table sync worker for
>> a table that had been removed from pg_subscription_rel.
>
Hmm, forcibly stopping currently running table sync is not what was
intended, I'll have to look into it. We should not be forcibly stopping
anything except the main apply worker during drop subscription (and we
do that only because we can't drop the remote replication slot otherwise).
> Also, until commit the transaction the worker cannot launch new table
> sync worker due to conflicting tuple lock on pg_subscription_rel.
>
That part is correct, we don't know if the transaction will be rolled
back or not so we can't start workers as the state of the data in the
table in unknown.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services