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

On Thu, Dec 21, 2023 at 09:37:39AM +0530, Amit Kapila wrote:
> It depends on how one uses the function. For example, if one finds
> there is a conflict via pg_get_replication_slots() and wants to check
> the reason for the same via this new function then it would give the
> correct answer.

My point is that we may not get the "correct" answer at all :/

What guarantee do you have that between the scan of
pg_get_replication_slots() to get the value of "conflicting" and the
call of pg_get_slot_invalidation_cause() the slot state will still be
the same?  A lot could happen between both function calls while the
repslot LWLock is not hold.

> Now, if we think it is okay to have two columns
> 'conflicting' and 'conflict_reason/conflict_cause' to be returned by
> pg_get_replication_slots() then that should serve the purpose as well
> but one can argue that 'conflicting' is deducible from
> 'conflict_reason'.

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.
--
Michael