Avoid direct C access to possibly-null pg_subscription_rel.srsublsn.
This coding technique is unsafe, since we'd be accessing off the end
of the tuple if the field is null. SIGSEGV is pretty improbable, but
perhaps not impossible. Also, returning garbage for the LSN doesn't
seem like a great idea, even if callers aren't looking at it today.
Also update docs to point out explicitly that
pg_subscription.subslotname and pg_subscription_rel.srsublsn
can be null.
Perhaps we should mark these two fields BKI_FORCE_NULL, so that
they'd be correctly labeled in databases that are initdb'd in the
future. But we can't force that for existing databases, and on
balance it's not too clear that having a mix of different catalog
contents in the field would be wise.
Apply to v10 (where this code came in) through v12. Already
fixed in v13 and HEAD.
Discussion: https://postgr.es/m/732838.1595278439@sss.pgh.pa.us
Branch
------
REL_10_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/ae3d40b0cdc6bff33ad3caf5e8766b85ebe24168
Modified Files
--------------
doc/src/sgml/catalogs.sgml | 9 ++++++---
src/backend/catalog/pg_subscription.c | 18 ++++++++++++++++--
src/include/catalog/pg_subscription_rel.h | 13 +++++++++++--
3 files changed, 33 insertions(+), 7 deletions(-)
