Re: replication slot restart_lsn initialization
От | Andres Freund |
---|---|
Тема | Re: replication slot restart_lsn initialization |
Дата | |
Msg-id | 20150814075400.GE4955@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: replication slot restart_lsn initialization (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: replication slot restart_lsn initialization
Re: replication slot restart_lsn initialization Re: replication slot restart_lsn initialization |
Список | pgsql-hackers |
On 2015-08-14 16:44:44 +0900, Michael Paquier wrote: > Commit 6fcd8851, which is the result of this thread, is not touching > the replication protocol at all. This looks like an oversight to me: > we should be a maximum consistent between the SQL interface and the > replication protocol if possible, and it looks useful to me to be able > to set restart_lsn when creating the slot as well when using a > replication connection. It wasn't, at least not from my side. You can relatively easily do nearly the same just by connecting to the slot and sending a feedback message. The complaint upthread (and/or a related thread) was that it's not possible to do the same from SQL. It'd be a good additional to offer the same facility to the replication protocol. > For now we can do that: CREATE_REPLICATION_SLOT IDENT K_PHYSICAL We > could append a keyword like RESERVE on this query. Or go through more > fancy things like (slot_options) where slot_options is a list of > option items, reserve = on/off. Thoughts? -- Michael I'd name it RESERVE_WAL. My feeling is that the options for the logical case are geared towards the output plugin, not the walsender. I think it'd be confusing to use (slot_options) differently for physical slots. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: