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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
