Hi, 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.
One of the use case scenarios for this function is another ongoing thread "Synchronizing slots from primary to standby" at [1]. This function is needed there to replicate invalidation-cause of a logical replication slot from the primary server to the hot standby. But this is an independent requirement in itself and thus makes sense to have it implemented separately.
Agree. My thoughts about it: 1 === "Currently, users do not have a way to know the invalidation cause" I'm not sure about it, I think one could see the reasons in the log file. 2 === "This function returns NULL if the replication slot is not found" Why not returning an error instead? (like pg_drop_replication_slot() does for example) FWIW, we'd not need to cover this case if the description would be added to pg_replication_slots. 3 === + <para> + <literal>3</literal> = wal_level insufficient for the slot + </para> wal_level insufficient on the primary maybe? 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. 5 === doc/src/sgml/func.sgml | 33 +++++++++++++++++++++++++++++++++ src/backend/replication/slotfuncs.c | 27 +++++++++++++++++++++++++++ src/include/catalog/pg_proc.dat | 4 ++++ Worth to add some coverage in 019_replslot_limit.pl and 035_standby_logical_decoding.pl? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
