On Sun, Sep 17, 2017 at 2:01 AM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > On Sat, Sep 16, 2017 at 9:52 PM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: >> On 9/15/17 13:35, Arseny Sher wrote: >>> Peter Eisentraut <peter.eisentr...@2ndquadrant.com> 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 still >>> enabled? >> >> Yeah, we could just remove the _at_commit() branch entirely. That would >> effectively undo the change in 7e174fa793a2df89fe03d002a5087ef67abcdde8, >> but I don't see any other choice for now. And the practical impact >> would be quite limited. >> > > Yeah, we can remove only _at_commit() branch, but other part of the > commit is still valid for ALTER SUBSCRIPTION DISABLE. > >>> Besides, we can avoid stopping the workers if subscription has no >>> associated replication origin, though this probably means that >>> subscription was broken by user and is not worth it. >> >> Right, it seems not worth addressing this case separately. >> > > 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 case. In the latter case, we > adopted such non-transactional behaviour. Since these behaviours would > be complex for users I attached the documentation patch explaining it. >
Hmm, isn't there necessary to care and mention about this kind of inconsistent behavior in docs? 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
