On Fri, Jan 3, 2014 at 10:12 AM, Andres Freund <and...@2ndquadrant.com> wrote: > 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?
Yep, no objections. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
