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