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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
