DROP SUBSCRIPTION hangs if sub is disabled in the same transaction
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 ;
alter subscription s set (slot_name = none);
drop subscription s;
end;
It hangs in replorigin_drop because we wait until ReplicationState is
released. This should happen on exit of worker, but worker will not exit
until transaction commit because he doesn't see that the sub was
disabled.
Attached patch fixes this by stopping workers before RO drop, as
already done in case when we drop replication slot. I am not sure
whether this is a proper solution, but for now I don't see any problems
with early stop of workers: even if transaction later aborts, launcher
will happily restart them, isn't it?
--
Arseny Sher
Postgres Professional: https://postgrespro.ru
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Arseny Sher <a.sher@postgrespro.ru> 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.
Attachments:
0001-Stop-LR-workers-before-dropping-replication-origin.patchtext/x-diffDownload+9-7
On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher <a.sher@postgrespro.ru> wrote:
Arseny Sher <a.sher@postgrespro.ru> 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 item.
The cause of this is commit 7e174fa7 which make subscription ddls kill
the apply worker only when transaction commit. I didn't look the patch
deeply yet but I'm not sure the approach that kills apply worker
before commit would be good.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 06, 2017 at 03:28:47PM +0900, Masahiko Sawada wrote:
On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher <a.sher@postgrespro.ru> wrote:
Arseny Sher <a.sher@postgrespro.ru> 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 item.
The cause of this is commit 7e174fa7 which make subscription ddls kill
the apply worker only when transaction commit. I didn't look the patch
deeply yet but I'm not sure the approach that kills apply worker
before commit would be good.
[Action required within three days. This is a generic notification.]
The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1]/messages/by-id/20170404140717.GA2675809@tornado.leadboat.com and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.
[1]: /messages/by-id/20170404140717.GA2675809@tornado.leadboat.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 07, 2017 at 04:53:12AM +0000, Noah Misch wrote:
On Wed, Sep 06, 2017 at 03:28:47PM +0900, Masahiko Sawada wrote:
On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher <a.sher@postgrespro.ru> wrote:
Arseny Sher <a.sher@postgrespro.ru> 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 item.
The cause of this is commit 7e174fa7 which make subscription ddls kill
the apply worker only when transaction commit. I didn't look the patch
deeply yet but I'm not sure the approach that kills apply worker
before commit would be good.[Action required within three days. This is a generic notification.]
The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.[1] /messages/by-id/20170404140717.GA2675809@tornado.leadboat.com
This PostgreSQL 10 open item is past due for your status update. Kindly send
a status update within 24 hours, and include a date for your subsequent status
update. Refer to the policy on open item ownership:
/messages/by-id/20170404140717.GA2675809@tornado.leadboat.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/10/17 12:14, Noah Misch wrote:
This PostgreSQL 10 open item is past due for your status update. Kindly send
a status update within 24 hours, and include a date for your subsequent status
update. Refer to the policy on open item ownership:
/messages/by-id/20170404140717.GA2675809@tornado.leadboat.com
I'm looking into this now and will report tomorrow.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 6, 2017 at 3:28 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher <a.sher@postgrespro.ru> wrote:
Arseny Sher <a.sher@postgrespro.ru> 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 item.
The cause of this is commit 7e174fa7 which make subscription ddls kill
the apply worker only when transaction commit. I didn't look the patch
deeply yet but I'm not sure the approach that kills apply worker
before commit would be good.
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 subscription had
been removed.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Masahiko Sawada <sawada.mshk@gmail.com> 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 subscription had
been removed.
I don't think this is reliable -- what if worker suddenly dies without
accomplishing the job? It is enough to kill the worker during execution
of (possibly long) transaction with DROP SUBSCRIPTION to meet such
situation. Dropping replication origin in one transaction with DROP
SUBSCRIPTION seems natural to me.
--
Arseny Sher
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 wait until ReplicationState is
released. This should happen on exit of worker, but worker will not exit
until transaction commit because he doesn't see that the sub was
disabled.
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 these things at once,
you get this circular dependency.
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.
- Revert to the old behavior that the replication origin dropping fails
if it is in use. Then you would get an error instead of hanging. But
that was previously also reported as a bug.
- Disallow DROP SUBSCRIPTION in a transaction under certain
circumstances, for example if a transaction has previously manipulated
the same subscription.
- Have DROP SUBSCRIPTION attempt to kill workers if the subscription is
disabled (and possibly, was changed in the same transaction), which
would address this scenario very narrowly.
Maybe there are more ideas. But I think we have to pick a poison.
Thoughts?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/11/17 14:26, Peter Eisentraut wrote:
On 9/10/17 12:14, Noah Misch wrote:
This PostgreSQL 10 open item is past due for your status update. Kindly send
a status update within 24 hours, and include a date for your subsequent status
update. Refer to the policy on open item ownership:
/messages/by-id/20170404140717.GA2675809@tornado.leadboat.comI'm looking into this now and will report tomorrow.
I need some community feedback on the possible solutions. I will wait
until Thursday.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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 these things at once,
you get this circular dependency.
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.
- Revert to the old behavior that the replication origin dropping fails
if it is in use. Then you would get an error instead of hanging. But
that was previously also reported as a bug.
- Disallow DROP SUBSCRIPTION in a transaction under certain
circumstances, for example if a transaction has previously manipulated
the same subscription.
- Have DROP SUBSCRIPTION attempt to kill workers if the subscription is
disabled (and possibly, was changed in the same transaction), which
would address this scenario very narrowly.
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 after we look for
workers?
If there aren't variants of that that will break all four options,
it's not very obvious why not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 13, 2017 at 12:48 AM, Arseny Sher <a.sher@postgrespro.ru> wrote:
Masahiko Sawada <sawada.mshk@gmail.com> 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 subscription had
been removed.
After thought, I think we can change it like followings.
* If the replication origin is not acquired, DROP SUBSCRIPTION can drop it.
* If the replication origin is acquired by someone DROP SUBSCRIPTION
takes over a job of dropping it to the apply worker.
* The apply worker drops the replication origin when exit if the apply
worker has to drop it.
I don't think this is reliable -- what if worker suddenly dies without
accomplishing the job?
The apply worker will be launched by the launcher later. If DROP
SUBSCRIPTION is issued before the apply worker launches again, DROP
SUBSCRIPTION itself can remove the replication origin.
Attached a very rough patch for reference. It's very ugly but we can
deal with this case.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachments:
very_rough_repl_origin.patchtext/x-patch; charset=US-ASCII; name=very_rough_repl_origin.patchDownload+42-7
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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 (and possibly, was changed in the same transaction), which
would address this scenario very narrowly.
Actually, my patch is closer to the last variant. I proposed to kill the
workers in DROP SUBSCRIPTION, and only if we are dropping replication
origin (which is probably always the case, though). I agree that it is
somewhat narrow and still slightly violates transactionality of DROP
SUBSCRIPTION, meaning that its changes (stopped workers) are seen before
the commit.
However, do we care much about that? Is there any chance that users will
rely on living apply workers after DROP SUBSCRIPTION, but before the
transaction commit? In which situation this might be useful?
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 as
long as Postgres doesn't have autonomous transactions.
Tom Lane <tgl@sss.pgh.pa.us> writes:
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 after we look for
workers?
We hold a lock on subscription till the end of transaction, so workers
won't start.
If there aren't variants of that that will break all four options,
it's not very obvious why not.
I see it this way:
* We want effect of drop sub invisible till commit, so we can't stop
workers before commit.
* Drop of replication origin needs to be executed in one transaction with
drop sub, it writes to WAL and so must be executed before commit.
* Apply worker needs RO for its work, it owns origin for the whole
lifetime.
Something should be given up here. One more idea that was not yet
mentioned is to abandon attempts to drop subs and ROs simultenously and
just garbage-collect replication origins periodically, but that doesn't
sound as an elegant solution.
Masahiko Sawada <sawada.mshk@gmail.com> writes:
I don't think this is reliable -- what if worker suddenly dies without
accomplishing the job?The apply worker will be launched by the launcher later. If DROP
SUBSCRIPTION is issued before the apply worker launches again, DROP
SUBSCRIPTION itself can remove the replication origin.
Why launcher would restart the worker if we already destroyed the
subscription? Consider the sequence of actions:
* We check in DROP SUBSCRIPTION that worker alive and don't remove RO.
* DROP SUBSCRIPTION commits.
* Worker is killed by some villain before it had the chance to drop RO.
It might be killed even before drop sub commit, but after the check,
we are left with orphan RO anyway.
--
Arseny Sher
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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 least surprising behavior.
+1 for that option. IIRC this has precedent for other object types such
as tables, where we refuse some action if we have already operated on
the table in the same transaction.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 13, 2017 at 8:00 PM, Arseny Sher <a.sher@postgrespro.ru> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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 (and possibly, was changed in the same transaction), which
would address this scenario very narrowly.Actually, my patch is closer to the last variant. I proposed to kill the
workers in DROP SUBSCRIPTION, and only if we are dropping replication
origin (which is probably always the case, though). I agree that it is
somewhat narrow and still slightly violates transactionality of DROP
SUBSCRIPTION, meaning that its changes (stopped workers) are seen before
the commit.However, do we care much about that? Is there any chance that users will
rely on living apply workers after DROP SUBSCRIPTION, but before the
transaction commit? In which situation this might be useful?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 as
long as Postgres doesn't have autonomous transactions.Tom Lane <tgl@sss.pgh.pa.us> writes:
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 after we look for
workers?We hold a lock on subscription till the end of transaction, so workers
won't start.If there aren't variants of that that will break all four options,
it's not very obvious why not.I see it this way:
* We want effect of drop sub invisible till commit, so we can't stop
workers before commit.
* Drop of replication origin needs to be executed in one transaction with
drop sub, it writes to WAL and so must be executed before commit.
* Apply worker needs RO for its work, it owns origin for the whole
lifetime.Something should be given up here. One more idea that was not yet
mentioned is to abandon attempts to drop subs and ROs simultenously and
just garbage-collect replication origins periodically, but that doesn't
sound as an elegant solution.Masahiko Sawada <sawada.mshk@gmail.com> writes:
I don't think this is reliable -- what if worker suddenly dies without
accomplishing the job?The apply worker will be launched by the launcher later. If DROP
SUBSCRIPTION is issued before the apply worker launches again, DROP
SUBSCRIPTION itself can remove the replication origin.Why launcher would restart the worker if we already destroyed the
subscription?
Ah, the apply worker will not launch in that case.
Consider the sequence of actions:
* We check in DROP SUBSCRIPTION that worker alive and don't remove RO.
* DROP SUBSCRIPTION commits.
* Worker is killed by some villain before it had the chance to drop RO.
It might be killed even before drop sub commit, but after the check,
we are left with orphan RO anyway.
Hmm yes, we could left with orphan the replication origin. It's not a
good solution.
The second option makes subscription management more complex for
users. Whenever user wants to drop subscription in use, they have to
disable it before dropping the subscription, while CREATE SUBSCRIPTION
starts the logical replication without ALTER SUBSCRIPTION ENABLE. I
guess disallowing DROP SUBSCRIPTION in a transaction would rather be
more useful for users because there would not be a lot of users who
want to manage subscriptions transactionally.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 14, 2017 at 12:04 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Wed, Sep 13, 2017 at 8:00 PM, Arseny Sher <a.sher@postgrespro.ru> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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 (and possibly, was changed in the same transaction), which
would address this scenario very narrowly.Actually, my patch is closer to the last variant. I proposed to kill the
workers in DROP SUBSCRIPTION, and only if we are dropping replication
origin (which is probably always the case, though). I agree that it is
somewhat narrow and still slightly violates transactionality of DROP
SUBSCRIPTION, meaning that its changes (stopped workers) are seen before
the commit.However, do we care much about that? Is there any chance that users will
rely on living apply workers after DROP SUBSCRIPTION, but before the
transaction commit? In which situation this might be useful?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 as
long as Postgres doesn't have autonomous transactions.Tom Lane <tgl@sss.pgh.pa.us> writes:
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 after we look for
workers?We hold a lock on subscription till the end of transaction, so workers
won't start.If there aren't variants of that that will break all four options,
it's not very obvious why not.I see it this way:
* We want effect of drop sub invisible till commit, so we can't stop
workers before commit.
* Drop of replication origin needs to be executed in one transaction with
drop sub, it writes to WAL and so must be executed before commit.
* Apply worker needs RO for its work, it owns origin for the whole
lifetime.Something should be given up here. One more idea that was not yet
mentioned is to abandon attempts to drop subs and ROs simultenously and
just garbage-collect replication origins periodically, but that doesn't
sound as an elegant solution.Masahiko Sawada <sawada.mshk@gmail.com> writes:
I don't think this is reliable -- what if worker suddenly dies without
accomplishing the job?The apply worker will be launched by the launcher later. If DROP
SUBSCRIPTION is issued before the apply worker launches again, DROP
SUBSCRIPTION itself can remove the replication origin.Why launcher would restart the worker if we already destroyed the
subscription?Ah, the apply worker will not launch in that case.
Consider the sequence of actions:
* We check in DROP SUBSCRIPTION that worker alive and don't remove RO.
* DROP SUBSCRIPTION commits.
* Worker is killed by some villain before it had the chance to drop RO.
It might be killed even before drop sub commit, but after the check,
we are left with orphan RO anyway.Hmm yes, we could left with orphan the replication origin. It's not a
good solution.The second option makes subscription management more complex for
users. Whenever user wants to drop subscription in use, they have to
disable it before dropping the subscription, while CREATE SUBSCRIPTION
starts the logical replication without ALTER SUBSCRIPTION ENABLE. I
guess disallowing DROP SUBSCRIPTION in a transaction would rather be
more useful for users because there would not be a lot of users who
want to manage subscriptions transactionally.
Sorry, "The second option" meant the second option of options listed by Peter.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/13/17 09:56, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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 least surprising behavior.+1 for that option. IIRC this has precedent for other object types such
as tables, where we refuse some action if we have already operated on
the table in the same transaction.
What are some examples of such behavior?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
On 9/13/17 09:56, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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 least surprising behavior.+1 for that option. IIRC this has precedent for other object types such
as tables, where we refuse some action if we have already operated on
the table in the same transaction.What are some examples of such behavior?
Search for CheckTableNotInUse() callers.
/me hates that the error messages are split across lines
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 <peter.eisentraut@2ndquadrant.com> 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 least surprising behavior.+1 for that option. IIRC this has precedent for other object types such
as tables, where we refuse some action if we have already operated on
the table in the same transaction.What are some examples of such behavior?
Search for CheckTableNotInUse() callers.
That one uses the relcache refcount, so we can't use that mechanism
here. I think we need something based on xmin. The enum code has
something like it, but I don't understand the details.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 we need to optimize. We
just need to prevent it from hanging.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers