Re: Function to get invalidation cause of a replication slot.

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Function to get invalidation cause of a replication slot.
Date: 2023-12-21 03:17:27
Message-ID: ZYOuR7RtYaXbzX8_@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 20, 2023 at 12:43:45PM +0100, Drouvot, Bertrand wrote:
> + <literal>3</literal> = wal_level insufficient on the primary server
>
> "." is missing at the end (to be consistent with 1 and 2). Same
> in the commit message.
>
> + * Returns ReplicationSlotInvalidationCause enum value for valid slot_name;
>
> Not sure the sentence should finish with ";".
>
> Another Nit is to add a comment in ReplicationSlotInvalidationCause definition (slot.h)
> that any new enum values (if any) should be added after the ones that are already defined (to
> provide some consistency across changes in this area if any).
>
> Except the above Nit(s) the patch LGTM.

This patch has a problem: this design can easily cause the report of
data inconsistent with pg_replication_slots because the data returned
by pg_get_replication_slots() and pg_get_slot_invalidation_cause()
would happen across *two* function call contexts, no? So, it seems to
me that this had better be integrated as an extra column of
pg_get_replication_slots() to ensure the consistency of the data
reported. And it's critical to get consistent data for monitoring.

Not to mention that the lookup had better happen also while holding
ReplicationSlotControlLock as well, which is also something
InvalidatePossiblyObsoleteSlot() relies on. v2 ignores that.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-12-21 03:25:19 Re: Add new for_each macros for iterating over a List that do not require ListCell pointer
Previous Message Nathan Bossart 2023-12-21 03:16:14 Re: pg_upgrade failing for 200+ million Large Objects