Re: Non-reserved replication slots and slot advancing
От | Andres Freund |
---|---|
Тема | Re: Non-reserved replication slots and slot advancing |
Дата | |
Msg-id | 20180703165553.ycls2dup5gwynynx@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Non-reserved replication slots and slot advancing (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Non-reserved replication slots and slot advancing
|
Список | pgsql-hackers |
Hi, On 2018-06-26 16:13:05 +0900, Michael Paquier wrote: > I have been chewing for the last couple of days on this email from > Horiguchi-san: > https://www.postgresql.org/message-id/20180622.163312.254556300.horiguchi.kyotaro@lab.ntt.co.jp > > As summarized, it is actually strange to be able to advance a slot which > has a non-reserved restart_lsn. For example, take that which can happen > on HEAD: > =# select pg_create_physical_replication_slot('toto'); > pg_create_physical_replication_slot > ------------------------------------- > (toto,) > (1 row) > =# select pg_replication_slot_advance('toto', '0/1'); > pg_replication_slot_advance > ----------------------------- > (toto,0/1) > (1 row) > =# select slot_name, restart_lsn from pg_replication_slots ; > slot_name | restart_lsn > -----------+------------- > toto | 0/1 > (1 row) 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? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: