Re: Function to get invalidation cause of a replication slot. - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Function to get invalidation cause of a replication slot.
Date
Msg-id ZYPdNnEz1oIN2Zdb@paquier.xyz
Whole thread Raw
In response to Re: Function to get invalidation cause of a replication slot.  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Function to get invalidation cause of a replication slot.
List pgsql-hackers
On Thu, Dec 21, 2023 at 11:53:04AM +0530, Amit Kapila wrote:
> On Thu, Dec 21, 2023 at 11:18 AM Michael Paquier <michael@paquier.xyz> wrote:
> Yeah, if one uses them independently then there is no such guarantee.

This could be possible in the same query as well, still less likely,
as the contents are volatile.

>>  A lot could happen between both function calls while the
>> repslot LWLock is not hold.
>>
>> Yeah, you could keep the reason text as NULL when there is no
>> conflict, replacing the boolean by the text in the function, and keep
>> the view definition compatible with v16 while adding an extra column.
>
> But as mentioned we also want the enum value to be exposed in some way
> so that it can be used by the sync slot feature [1] as well,
> otherwise, we may need some mappings to convert the text back to an
> enum. I guess if we want to expose via view, then we can return an
> enum value by pg_get_replication_slots() and the view can replace it
> with text based on the value.

Sure.  Something like is OK by me as long as the data is retrieved
from a single scan of the slot data while holding the slot data's
LWLock.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Remove MSVC scripts from the tree
Next
From: Dilip Kumar
Date:
Subject: Re: index prefetching