On Fri, Jan 3, 2014 at 10:12 AM, Andres Freund <andres@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 <andres@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