Horton

Re: pg_receivewal starting position

Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>

View thread View on postgr.es
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Ronan Dunklau <ronan.dunklau@aiven.io>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2021-09-01T05:00:05Z
Lists: pgsql-hackers 
On Mon, Aug 30, 2021 at 3:26 PM Ronan Dunklau <ronan.dunklau@aiven.io> wrote:
> > 7) How about we let pg_receivewal use READ_REPLICATION_SLOT as an option?
>
> From my point of view, I already expected it to use something like that when
> using a replication slot. Maybe an option to turn it off could be useful ?

IMO, pg_receivewal should have a way to turn off/on using
READ_REPLICATION_SLOT. Imagine if the postgres server doesn't support
READ_REPLICATION_SLOT (a lower version) but for some reasons the
pg_receivewal(running separately) is upgraded to the version that uses
READ_REPLICATION_SLOT, knowing that the server doesn't support
READ_REPLICATION_SLOT why should user let pg_receivewal run an
unnecessary code?

Regards,
Bharath Rupireddy.

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()