aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeIncrementalSort.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-07-19 12:37:23 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-07-19 12:37:23 -0400
commit72eab84a565cbc0677bf8907cd4bfaddf064bd64 (patch)
treecb6015ccdf6926b7bfcd528f424abbf276ba52da /src/backend/executor/nodeIncrementalSort.c
parent4d3db13621be64fbac2faf7c01c4879d20885c1b (diff)
downloadpostgresql-72eab84a565cbc0677bf8907cd4bfaddf064bd64.tar.gz
postgresql-72eab84a565cbc0677bf8907cd4bfaddf064bd64.zip
Correctly mark pg_subscription.subslotname as nullable.
Due to the layout of this catalog, subslotname has to be explicitly marked BKI_FORCE_NULL, else initdb will default to the assumption that it's non-nullable. Since, in fact, CREATE/ALTER SUBSCRIPTION will store null values there, the existing marking is just wrong, and has been since this catalog was invented. We haven't noticed because not much in the system actually depends on attnotnull being truthful. However, JIT'ed tuple deconstruction does depend on that in some cases, allowing crashes or wrong answers in queries that inspect pg_subscription. Commit 9de77b545 quite accidentally exposed this on the buildfarm members that force JIT activation. Back-patch to v13. The problem goes further back, but we cannot force initdb in released branches, so some klugier solution will be needed there. Before working on that, push this simple fix to try to get the buildfarm back to green. Discussion: https://postgr.es/m/4118109.1595096139@sss.pgh.pa.us
Diffstat (limited to 'src/backend/executor/nodeIncrementalSort.c')
0 files changed, 0 insertions, 0 deletions