On 2013-12-12 10:01:21 -0500, Robert Haas wrote: > On Thu, Dec 12, 2013 at 7:04 AM, Andres Freund <and...@2ndquadrant.com> wrote: > > I think there'll always be a bit of a difference between slots for > > physical and logical data, even if 90% of the implementation is the > > same. We can signal that difference by specifying logical/physical as an > > option or having two different sets of commands. > > > > Maybe? > > > > ACQUIRE_REPLICATION_SLOT slot_name PHYSICAL physical_opts > > ACQUIRE_REPLICATION_SLOT slot_name LOGICAL logical_opts > > -- already exists without slot, PHYSICAL arguments > > START_REPLICATION [SLOT slot] [PHYSICAL] RECPTR opt_timeline > > START_REPLICATION SLOT LOGICAL slot plugin_options > > RELEASE_REPLICATION_SLOT slot_name > > I assume you meant START_REPLICATION SLOT slot LOGICAL plugin_options, > but basically this seems OK to me.
When writing the code for this, I decided that I need to reneg a bit on those names - they don't work nicely enough on the C level for me. Specifically during a START_REPLICATION we need to temporarily mark the slot as being actively used and mark it unused again afterwards. That's much more Acquire/Release like than the persistent Acquire/Release above for me. The C names in the version I am working on currently are: extern void ReplicationSlotCreate(const char *name); extern void ReplicationSlotDrop(const char *name); extern void ReplicationSlotAcquire(const char *name); extern void ReplicationSlotRelease(void); extern void ReplicationSlotSave(void); which would make the walsender ones CREATE_REPLICATION_SLOT ... START_REPLICATION [SLOT slot] [LOGICAL | PHYSICAL] ... DROP_REPLICATION_SLOT ... where START_REPLICATION internally does acquire/release on the passed SLOT. Does that work for you? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers