Re: replication slot restart_lsn initialization

From: Andres Freund <andres(at)anarazel(dot)de>
To: "Duran, Danilo" <danilod(at)amazon(dot)com>
Cc: "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replication slot restart_lsn initialization
Date: 2015-05-06 00:53:23
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-05-06 02:00:11 Re: Implementing SQL ASSERTION
Previous Message Duran, Danilo 2015-05-06 00:42:14 replication slot restart_lsn initialization