pgsql: Avoid direct C access to possibly-null pg_subscription_rel.srsub
От | Tom Lane |
---|---|
Тема | pgsql: Avoid direct C access to possibly-null pg_subscription_rel.srsub |
Дата | |
Msg-id | E1jxuO3-0001yv-PF@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
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_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b7103bbe34aa3d66f4618d0abdee5d3107ea8f91 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(-)
В списке pgsql-committers по дате отправления: