Horton

Re: pg_receivewal starting position

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Ronan Dunklau <ronan.dunklau@aiven.io>
Cc: pgsql-hackers@lists.postgresql.org, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2021-10-25T07:40:10Z
Lists: pgsql-hackers 
On Mon, Oct 25, 2021 at 09:15:32AM +0200, Ronan Dunklau wrote:
> Does it make sense though ? The NULL slot_name case handling is pretty 
> straight forward has it will be handled by string formatting, but in the case 
> of a null restart_lsn, we have no way of knowing if the command was issued at 
> all.

If I am following your point, I don't think that it matters much here,
and it seems useful to me to be able to pass NULL for both of them, so
as one can check if the slot exists or not with an API designed this
way.
--
Michael

Commits

  1. Add TAP test for pg_receivewal with timeline switch

  2. Speed up TAP tests of pg_receivewal

  3. Allow pg_receivewal to stream from a slot's restart LSN

  4. Add replication command READ_REPLICATION_SLOT

  5. doc: Describe calculation method of streaming start for pg_receivewal

  6. Add PostgresNode::command_fails_like()