Hi,
On 2015-05-06 00:42:14 +0000, Duran, Danilo wrote:
> I am looking to better understand the thought behind a replication
> slot's restart_lsn initialization. Currently in 9.4 and master, a
> replication slot's restart_lsn is set to InvalidXLogRecPtr and will
> only start tracking restart_lsn once a walreceiver has confirmed
> receipt of an lsn.
Right, for physical slots that's true.
> Was there any consideration for initializing restart_lsn to the latest
> WAL write pointer when a slot is created? Or for allowing an optional
> parameter in pg_create_(physical|logical)_replication_slot() for
> specifying the restart_lsn at slot creation?
I've been wondering about allowing for the latter alternative. I could
have used it a couple times. The former doesn't make much sense to me,
it could be too far *ahead* in many cases actually. A patch for this
would be fairly trivial.
It doesn't make sense for logical slots (as the computation of the
initial lsn is more complicated; it's also also already set when you
create one.
> I believe there are valid usage patterns where the user would like to
> start holding transaction logs from being removed/recycled during the
> time that the standby is being restored from base backup. Currently
> this can be worked around by using pg_receivexlog immediately after
> creating the replication slot but it feels kind of hacky.
Yea, that's what I've done as well. I'd much rather have a proper option
for it.
> It is also strange that the return type for
> pg_create_(physical|logical)_replication_slot includes xlog_position
> but as far as I can tell, it will never contain a value. Is this
> intended for something in the future?
It'll contain something for logical slots. I wanted the physical version
to be analogous, with the thought of adding a different signature at
some point.
Greetings,
Andres Freund