Thread: pgsql: Allow pg_create_physical_replication_slot() to reserve WAL.
Allow pg_create_physical_replication_slot() to reserve WAL. When creating a physical slot it's often useful to immediately reserve the current WAL position instead of only doing after the first feedback message arrives. That e.g. allows slots to guarantee that all the WAL for a base backup will be available afterwards. Logical slots already have to reserve WAL during creation, so generalize that logic into being usable for both physical and logical slots. Catversion bump because of the new parameter. Author: Gurjeet Singh Reviewed-By: Andres Freund Discussion: CABwTF4Wh_dBCzTU=49pFXR6coR4NW1ynb+vBqT+Po=7fuq5iCw@mail.gmail.com Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/6fcd88511f8e69e38defb1272e0042ef4bab2feb Modified Files -------------- doc/src/sgml/func.sgml | 8 +++- src/backend/catalog/system_views.sql | 7 +++ src/backend/replication/logical/logical.c | 47 +------------------ src/backend/replication/slot.c | 71 +++++++++++++++++++++++++++++ src/backend/replication/slotfuncs.c | 21 ++++++++- src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_proc.h | 2 +- src/include/replication/slot.h | 1 + 8 files changed, 107 insertions(+), 52 deletions(-)
On Tue, Aug 11, 2015 at 7:47 PM, Andres Freund <andres@anarazel.de> wrote: > Allow pg_create_physical_replication_slot() to reserve WAL. > > When creating a physical slot it's often useful to immediately reserve > the current WAL position instead of only doing after the first feedback > message arrives. That e.g. allows slots to guarantee that all the WAL > for a base backup will be available afterwards. > > Logical slots already have to reserve WAL during creation, so generalize > that logic into being usable for both physical and logical slots. Why hasn't this addition been spread as well in the replication protocol? It seems to me that most of the refactoring work has been done with ReplicationSlotReserveWal. -- Michael
On 2015-08-14 15:32:17 +0900, Michael Paquier wrote: > Why hasn't this addition been spread as well in the replication > protocol? It seems to me that most of the refactoring work has been > done with ReplicationSlotReserveWal. Feel free to send a patch.
On Fri, Aug 14, 2015 at 3:50 PM, Andres Freund <andres@anarazel.de> wrote: > On 2015-08-14 15:32:17 +0900, Michael Paquier wrote: >> Why hasn't this addition been spread as well in the replication >> protocol? It seems to me that most of the refactoring work has been >> done with ReplicationSlotReserveWal. > > Feel free to send a patch. I don't mind giving it a try if time allows... CREATE_REPLICATION_SLOT IDENT K_PHYSICAL slot_options? With slot_options: (reserve = on/off)? And, actually, here is an unrelated patch, the docs are referring to confirmed_flush instead of confirmed_flush_lsn ;) -- Michael
Attachment
On 2015-08-14 16:03:51 +0900, Michael Paquier wrote: > On Fri, Aug 14, 2015 at 3:50 PM, Andres Freund <andres@anarazel.de> wrote: > > On 2015-08-14 15:32:17 +0900, Michael Paquier wrote: > >> Why hasn't this addition been spread as well in the replication > >> protocol? It seems to me that most of the refactoring work has been > >> done with ReplicationSlotReserveWal. > > > > Feel free to send a patch. > > I don't mind giving it a try if time allows... CREATE_REPLICATION_SLOT > IDENT K_PHYSICAL slot_options? With slot_options: (reserve = on/off)? Let's discuss that in the -hackers thread. I slightly doubt the generic options (which don't exist for CREATE) are a good place for that, they're for the output plugin, this isn't. I think a separate keyword might be easier. > And, actually, here is an unrelated patch, the docs are referring to > confirmed_flush instead of confirmed_flush_lsn ;) Ick, will apply. Greetings, Andres Freund