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

From: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(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-20 10:40:03
Message-ID: c476f76e-44eb-459d-a060-5b92408b1a26@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 12/20/23 9:50 AM, Amit Kapila wrote:
> On Wed, Dec 20, 2023 at 12:46 PM Drouvot, Bertrand
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>>
>> On 12/20/23 7:01 AM, shveta malik wrote:
>>> Hello hackers,
>>>
>>> Attached is a patch which attempts to implement a new system function
>>> pg_get_slot_invalidation_cause('slot_name') to get invalidation cause
>>> of a replication slot.
>>
>> Thanks! +1 for the idea to display this information through an SQL API.
>>
>> I wonder if we could add a new field to pg_replication_slots instead
>> of creating a new function.
>>
>
> Yeah, that is another option. We already have a boolean column
> 'conflicting' in pg_replication_slots, so are you suggesting adding a
> new column like 'conflict_cause'?

Yes.

> I feel it is okay to have an SQL
> function for this as it may be primarily used for internal purposes or
> for some specific users who want to dig deeper for the invalidation
> cause.
>
>> 4 ===
>>
>> + * Returns ReplicationSlotInvalidationCause enum value for valid slot_name;
>>
>> I think it would be more user friendly to return a description instead of an enum value.
>>
> But it would be tricky to use at a place where we want to know the
> enum value as in the case of the sync slots patch where we want to
> copy the cause.

Yeah right, what about displaying both then? (one field for the enum and one for
the description). I feel it's not friendly to ask users to refer to the documentation
(or the commit message) to get the meaning of the output.

Another option could be to create a new view, say pg_slot_invalidation_causes, that would list
them all (cause_id, cause_description) and then keep pg_get_slot_invalidation_cause() returning
the cause_id only.

Also I think we should 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).

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-12-20 10:44:49 Re: Function to get invalidation cause of a replication slot.
Previous Message Andres Freund 2023-12-20 10:30:01 Re: backtrace_on_internal_error