Hi,
On 12/20/23 9:50 AM, Amit Kapila wrote:
On Wed, Dec 20, 2023 at 12:46 PM Drouvot, Bertrand
<bertranddrouvot...@gmail.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
