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
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
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
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
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.
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
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
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
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
>>
>>
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
26 matches
Mail list logo