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>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2021-10-24T06:51:06Z
Lists: pgsql-hackers 
On Sun, Oct 24, 2021 at 09:08:01AM +0530, Bharath Rupireddy wrote:
> pg_get_replication_slots holds the ReplicationSlotControlLock until
> the end of the function so it can be assured that *slot contents will
> not change. In ReadReplicationSlot, the ReplicationSlotControlLock is
> released immediately after taking *slot pointer into slot_contents.
> Isn't it better if we hold the lock until the end of the function so
> that we can avoid the slot contents becoming stale problems?

The reason is different in the case of pg_get_replication_slots().  We
have to hold ReplicationSlotControlLock for the whole duration of the
shared memory scan to return back to the user a consistent set of
information to the user, for all the slots.
--
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()