Horton

Re: pg_receivewal starting position

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Ronan Dunklau <ronan.dunklau@aiven.io>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2021-09-06T07:17:28Z
Lists: pgsql-hackers 
On Mon, Sep 06, 2021 at 12:37:29PM +0530, Bharath Rupireddy wrote:
> -1 for READ_PHYSICAL_REPLICATION_SLOT or failing on the server. What
> happens if we have another slot type "PHYSIOLOGICAL" or "FOO" or "BAR"
> some other? IMO, READ_REPLICATION_SLOT should just return info of all
> slots. The clients know better how to deal with the slot type.
> Although, we don't have a use case for logical slots with the
> READ_REPLICATION_SLOT command, let's not change it.

Using READ_REPLICATION_SLOT as the command name is fine, and it could
be extended with more fields if necessary, implemented now with only
what we think is useful.  Returning errors on cases that are still not
supported yet is fine, say for logical slots if we decide to reject
the case for now, and testrictions can always be lifted in the
future.
--
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()