Date: Tue, 2 May 2017 18:15:30 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	Michael Paquier <michael.paquier@gmail.com>,
	PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: logical replication syntax (was DROP SUBSCRIPTION,
 query cancellations and slot handling)
Message-ID: <20170502211530.knjb72uo2lykuzxt@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+TgmoZGdsDmqDbRTmpgxb9bQttkQgbyXTwCV1QcVKMHfA1QdQ@mail.gmail.com>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas wrote:
> On Tue, May 2, 2017 at 12:25 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > 2) don't drop because we know it won't work.  I see two options:
> >    c) ignore a drop slot failure, i.e. don't cause a transaction abort.
> >       An easy way to implement this is just add a PG_TRY block, but we
> >       dislike adding those and not re-throwing the error.
> 
> Dislike doesn't seem like the right word.  Unless you rollback a
> (sub)transaction, none of the cleanup that would normally do is done,

True.  So one possible implementation is that we open a subtransaction
before dropping the slot, and we abort it if things go south.  This is a
bit slower, but not critically so.

-- 
Á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