Re: pg_stat_get_replication_slot() marked not strict, crashes
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2022-03-28T04:09:29Z
Lists: pgsql-hackers
Hi, On 2022-03-28 08:28:29 +0530, Amit Kapila wrote: > I am not sure if for 14 we can make a catalog change as that would > require catversion bump, so adding a code-level check as suggested by > Andres seems like a better option. Andres/Tom, any better ideas for > this? I think we could do the catalog change too, so that future initdb's are marked correctly. But we obviously do need the code-level check nevertheless. > Thanks for the patch but for HEAD, we also need handling and test for > pg_stat_get_subscription_stats. Considering this for HEAD, we can mark > both pg_stat_get_replication_slot and pg_stat_get_subscription_stats > as strict and in 14, we need to add a code-level check for > pg_stat_get_replication_slot. FWIW, I have a test for both, I was a bit "stuck" on where to put the pg_stat_get_subscription_stats(NULL) test. I had put the pg_stat_get_replication_slot(NULL) in contrib/test_decoding/sql/stats.sql but pg_stat_get_subscription_stats() doesn't really fit there. I think I'm coming down to putting a section of such tests into src/test/regress/sql/stats.sql instead. In the hope of preventing future such occurrances by encouraging people to copy the test... Greetings, Andres Freund
Commits
-
Mark pg_stat_get_subscription_stats() strict.
- da4b56662f2c 15.0 landed
-
Fix NULL input behaviour of pg_stat_get_replication_slot().
- 43a7dc96eb36 15.0 landed
- c1a0d7d1c4b7 14.3 landed