Re: Non-reserved replication slots and slot advancing

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>
Subject: Re: Non-reserved replication slots and slot advancing
Date: 2018-07-03 17:51:48
Message-ID: 20180703175148.vhjnh6bu2vijj5fh@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-Jul-03, Andres Freund wrote:

> On 2018-07-03 13:23:50 -0400, Alvaro Herrera wrote:
> > On 2018-Jul-03, Andres Freund wrote:
> >
> > > I'm not clear to why this is a problem? Seems like either behaviour can
> > > be argued for. I don't really have an opinion either way. I'd just
> > > remove the item from the open items list, I don't think we need to hold
> > > up the release for it?
> >
> > After reading this more carefully, isn't the problem that as soon as you
> > get a slot into the 0/1 restart_lsn state, WAL recycling/deletion no
> > longer happens? That does sound like a bad thing to me.
>
> Fair enough, but that's what a plain slot allows you as well, pretty
> fundamentally, no? The precise point at which recycling will be blocked
> will differer, sure.

Yeah, well, I suppose that other mechanisms to use slots are less of a
foot-gun -- by creating one their start_lsn is set to some reasonable
value. With slot advancing, it seems easier to get into trouble. Of
course, you can set the slot to a LSN that is valid now, and then not do
anything with it, in which case you're also screwed.

As I recall, this slot advancing business is new in pg11, and I think it
makes sense to provide a decent API that prevents you from doing
something extremely stupid.

Getting this fixed is +0.2 from me -- I'm not really on the side of this
being a severe bug as all that.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikhil Sontakke 2018-07-03 18:09:41 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Andres Freund 2018-07-03 17:37:24 Re: Non-reserved replication slots and slot advancing