On Sat, Sep 23, 2017 at 4:06 AM, Peter Eisentraut
wrote:
> On 9/21/17 04:43, Masahiko Sawada wrote:
>>> Once we got this patch, DROP SUBSCRIPTION is not transactional either
>>> if dropping a replication slot or if the subscription got disabled in
>>> a transaction block. But we disallow to do DRO
On 9/21/17 04:43, Masahiko Sawada wrote:
>> Once we got this patch, DROP SUBSCRIPTION is not transactional either
>> if dropping a replication slot or if the subscription got disabled in
>> a transaction block. But we disallow to do DROP SUBSCRIPTION in a
>> transaction block only in the former cas
Masahiko Sawada writes:
> On Sun, Sep 17, 2017 at 2:01 AM, Masahiko Sawada
> wrote:
>> +
>> + Since dropping a replication slot is not transactional, we cannot run
>> + DROP SUBSCRIPTION inside a transaction block if
>> dropping
>> + the replication slot. Also, DROP SUBSCRIPTOIN stops
On Sun, Sep 17, 2017 at 2:01 AM, Masahiko Sawada wrote:
> On Sat, Sep 16, 2017 at 9:52 PM, Peter Eisentraut
> wrote:
>> On 9/15/17 13:35, Arseny Sher wrote:
>>> Peter Eisentraut writes:
>>>
Here is a simple patch that fixes this, based on my original proposal
point #4.
>>>
>>> I checke
On 9/16/17 08:52, Peter Eisentraut wrote:
> On 9/15/17 13:35, Arseny Sher wrote:
>> Peter Eisentraut writes:
>>
>>> Here is a simple patch that fixes this, based on my original proposal
>>> point #4.
>> I checked, it passes the tests and solves the problem. However, isn't
>> this
>>
>> +
On Sat, Sep 16, 2017 at 9:52 PM, Peter Eisentraut
wrote:
> On 9/15/17 13:35, Arseny Sher wrote:
>> Peter Eisentraut writes:
>>
>>> Here is a simple patch that fixes this, based on my original proposal
>>> point #4.
>>
>> I checked, it passes the tests and solves the problem. However, isn't
>> thi
On 9/15/17 13:35, Arseny Sher wrote:
> Peter Eisentraut writes:
>
>> Here is a simple patch that fixes this, based on my original proposal
>> point #4.
>
> I checked, it passes the tests and solves the problem. However, isn't
> this
>
> + if (slotname || !subenabled)
>
> is a truis
Peter Eisentraut writes:
> Here is a simple patch that fixes this, based on my original proposal
> point #4.
I checked, it passes the tests and solves the problem. However, isn't
this
+ if (slotname || !subenabled)
is a truism? Is it possible that subscription has no slot but sti
On 9/14/17 15:47, Arseny Sher wrote:
> Peter Eisentraut writes:
>
>> On 9/13/17 07:00, Arseny Sher wrote:
>>> On the other hand, forbidding to execute disable sub and drop sub in one
>>> transaction makes it impossible e.g. to drop subscription in trigger
>>
>> Disabling a subscription before dro
Peter Eisentraut writes:
> On 9/13/17 07:00, Arseny Sher wrote:
>> On the other hand, forbidding to execute disable sub and drop sub in one
>> transaction makes it impossible e.g. to drop subscription in trigger
>
> Disabling a subscription before dropping it isn't very useful, is it?
> So I'm no
On 9/12/17 15:51, Tom Lane wrote:
> ISTM the second of those (refuse to drop an in-use subscription) is
> by far the least surprising behavior. However, I wonder if there aren't
> race conditions involved here. What if we haven't yet committed a
> DROP SUBSCRIPTION, and some new worker starts up
On 9/13/17 07:00, Arseny Sher wrote:
> On the other hand, forbidding to execute disable sub and drop sub in one
> transaction makes it impossible e.g. to drop subscription in trigger
Disabling a subscription before dropping it isn't very useful, is it?
So I'm not sure this is an important use case
On 9/14/17 08:23, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>> On 9/13/17 09:56, Alvaro Herrera wrote:
>>> Tom Lane wrote:
Peter Eisentraut writes:
>>>
> - Disallow DROP SUBSCRIPTION in a transaction under certain
> circumstances, for example if a transaction has previously mani
Peter Eisentraut wrote:
> On 9/13/17 09:56, Alvaro Herrera wrote:
> > Tom Lane wrote:
> >> Peter Eisentraut writes:
> >
> >>> - Disallow DROP SUBSCRIPTION in a transaction under certain
> >>> circumstances, for example if a transaction has previously manipulated
> >>> the same subscription.
> >
On 9/13/17 09:56, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Peter Eisentraut writes:
>
>>> - Disallow DROP SUBSCRIPTION in a transaction under certain
>>> circumstances, for example if a transaction has previously manipulated
>>> the same subscription.
>
>> ISTM the second of those (refuse to d
On Thu, Sep 14, 2017 at 12:04 AM, Masahiko Sawada wrote:
> On Wed, Sep 13, 2017 at 8:00 PM, Arseny Sher wrote:
>> Peter Eisentraut writes:
>>> We can break this in any number of ways:
>>>
>>> - (your patch) Kill workers right away after ALTER SUBSCRIPTION DISABLE,
>>> thus breaking the appearanc
On Wed, Sep 13, 2017 at 8:00 PM, Arseny Sher wrote:
> Peter Eisentraut writes:
>> We can break this in any number of ways:
>>
>> - (your patch) Kill workers right away after ALTER SUBSCRIPTION DISABLE,
>> thus breaking the appearance of transactional DDL somewhat.
>> ...
>> - Have DROP SUBSCRIPTI
Tom Lane wrote:
> Peter Eisentraut writes:
> > - Disallow DROP SUBSCRIPTION in a transaction under certain
> > circumstances, for example if a transaction has previously manipulated
> > the same subscription.
> ISTM the second of those (refuse to drop an in-use subscription) is
> by far the leas
Peter Eisentraut writes:
> We can break this in any number of ways:
>
> - (your patch) Kill workers right away after ALTER SUBSCRIPTION DISABLE,
> thus breaking the appearance of transactional DDL somewhat.
> ...
> - Have DROP SUBSCRIPTION attempt to kill workers if the subscription is
> disabled
On Wed, Sep 13, 2017 at 12:48 AM, Arseny Sher wrote:
> Masahiko Sawada writes:
>
>> FWIW, perhaps we can change the replication origin management so that
>> DROP SUBSCRIPTION doesn't drop the replication origin and the apply
>> worker itself removes it when exit. When an apply worker exits it
>>
Peter Eisentraut writes:
> I think we are whacking things around a in circle now. First we moved
> the worker killing to the end of the transaction to make subscription
> DDL transaction-capable. Then we changed replication origin dropping to
> wait until the worker detaches. If you do both of
On 9/4/17 10:41, Arseny Sher wrote:
> node 2:
> create table t (i int);
> create subscription s CONNECTION 'port=5432' publication p;
> begin;
> alter subscription s disable ;
> alter subscription s set (slot_name = none);
> drop subscription s;
> end;
>
> It hangs in replorigin_drop because we wa
Masahiko Sawada writes:
> FWIW, perhaps we can change the replication origin management so that
> DROP SUBSCRIPTION doesn't drop the replication origin and the apply
> worker itself removes it when exit. When an apply worker exits it
> removes the replication origin if the corresponding subscript
On Wed, Sep 6, 2017 at 3:28 PM, Masahiko Sawada wrote:
> On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher wrote:
>> Arseny Sher writes:
>>
>>> Attached patch fixes this by stopping workers before RO drop, as
>>> already done in case when we drop replication slot.
>>
>> Sorry, here is the patch.
>>
>
On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher wrote:
> Arseny Sher writes:
>
>> Attached patch fixes this by stopping workers before RO drop, as
>> already done in case when we drop replication slot.
>
> Sorry, here is the patch.
>
I could reproduce this issue, it's a bug. Added this to the open
Arseny Sher writes:
> Attached patch fixes this by stopping workers before RO drop, as
> already done in case when we drop replication slot.
Sorry, here is the patch.
>From 008d54dfe2e8ba610bb7c897cfbb4ee7a700aa2e Mon Sep 17 00:00:00 2001
From: Arseny Sher
Date: Mon, 4 Sep 2017 16:55:08 +0300
S
Hello,
Currently, DROP SUBSCRIPTION on REL_10_STABLE would block forever in the
following setup:
node 1:
create table t (i int);
create publication p for table t;
node 2:
create table t (i int);
create subscription s CONNECTION 'port=5432' publication p;
begin;
alter subscription s disable ;
alt
27 matches
Mail list logo
