From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Cc: Andres Freund <andres@anarazel.de>
Subject: Re: pg_subscription.subslotname is wrongly marked NOT NULL
Date: Sat, 18 Jul 2020 22:09:41 -0400
Message-ID: <34984.1595124581@sss.pgh.pa.us> (raw)
In-Reply-To: <4118109.1595096139@sss.pgh.pa.us>
References: <4118109.1595096139@sss.pgh.pa.us>
I wrote:
> In all branches back to v10, initdb marks pg_subscription.subslotname
> as NOT NULL: ...
> Nonetheless, CREATE/ALTER SUBSCRIPTION blithely set it to null
> when slot_name = NONE is specified.
> What would we like to do about this? Removing the NOT NULL
> marking wouldn't be too hard in HEAD, but telling users to
> fix it manually in the back branches seems like a mess.
After further thought, it seems like changing the definition that
subslotname is null for "NONE" is unworkable, because client-side
code might be depending on that. (pg_dump certainly is; we could
change that, but other code might have the same expectation.)
What I propose we do is
(1) Fix the NOT NULL marking in HEAD and v13. We could perhaps
alter it in older branches as well, but we cannot force initdb
so such a change would only affect newly-initdb'd installations.
(2) In pre-v13 branches, hack the JIT tuple deconstruction code
to be specifically aware that it can't trust attnotnull for
pg_subscription.subslotname. Yeah, it's ugly, but at least it's
not ugly going forwards.
I haven't looked to see where or how we might do (2), but I assume
it's possible.
> It's also a bit annoying that we have no mechanized checks that
> would catch this inconsistency. If JIT is going to be absolutely
> dependent on NOT NULL markings being accurate, we can't really
> have such a laissez-faire attitude to C code getting it wrong.
It seems like at least in assert-enabled builds, we'd better have
a cross-check for that. I'm not sure where's the best place.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org, andres@anarazel.de
Subject: Re: pg_subscription.subslotname is wrongly marked NOT NULL
In-Reply-To: <34984.1595124581@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox