On Fri, Aug 14, 2015 at 4:54 PM, Andres Freund <andres@anarazel.de> wrote:
> 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.
> [...]
> 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.
Well, this has taken less time than I thought:
=# CREATE_REPLICATION_SLOT toto PHYSICAL;
slot_name | consistent_point | snapshot_name | output_plugin
-----------+------------------+---------------+---------------
toto | 0/0 | null | null
(1 row)
=# CREATE_REPLICATION_SLOT toto2 PHYSICAL RESERVE_WAL;
slot_name | consistent_point | snapshot_name | output_plugin
-----------+------------------+---------------+---------------
toto2 | 0/0 | null | null
(1 row)
=# \q
$ psql -c 'select slot_name,restart_lsn from pg_replication_slots'
slot_name | restart_lsn
-----------+-------------
toto |
toto2 | 0/1738850
(2 rows)
What do you want to do with that? Do you wish to have a look at it or
should I register it in the next CF? I am fine with both, though this
is tightly linked with the feature already committed.
Regards,
--
Michael
