Re: Non-reserved replication slots and slot advancing
От | Alvaro Herrera |
---|---|
Тема | Re: Non-reserved replication slots and slot advancing |
Дата | |
Msg-id | 20180703175148.vhjnh6bu2vijj5fh@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Non-reserved replication slots and slot advancing (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Non-reserved replication slots and slot advancing
Re: Non-reserved replication slots and slot advancing |
Список | 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
В списке pgsql-hackers по дате отправления: