<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hello, <br /><br /> I am looking to
betterunderstand the thought behind a replication slot's restart_lsn initialization. Currently in 9.4 and master, a
replicationslot's restart_lsn is set to InvalidXLogRecPtr and will only start tracking restart_lsn once a walreceiver
hasconfirmed receipt of an lsn.<br /><br /> Was there any consideration for initializing restart_lsn to the latest WAL
writepointer 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?<br /><br /> I believe
thereare valid usage patterns where the user would like to start holding transaction logs from being removed/recycled
duringthe time that the standby is being restored from base backup. Currently this can be worked around by using
pg_receivexlogimmediately after creating the replication slot but it feels kind of hacky.<br /><br /> It is also
strangethat the return type for pg_create_(physical|logical)_replication_slot includes xlog_position but as far as I
cantell, it will never contain a value. Is this intended for something in the future?<br /><br /> Thanks,<br />
Danilo<br/></div>