Re: pg_subscription.subslotname is wrongly marked NOT NULL
От
Tom Lane
Тема
Re: pg_subscription.subslotname is wrongly marked NOT NULL
Дата
Msg-id
975217.1595349762@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
pg_subscription.subslotname is wrongly marked NOT NULL Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_subscription.subslotname is wrongly marked NOT NULL Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_subscription.subslotname is wrongly marked NOT NULL Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_subscription.subslotname is wrongly marked NOT NULL Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_subscription.subslotname is wrongly marked NOT NULL Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_subscription.subslotname is wrongly marked NOT NULL Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_subscription.subslotname is wrongly marked NOT NULL Tom Lane <tgl@sss.pgh.pa.us>
I wrote: > * On the other side of the ledger, if we don't fix these markings > we cannot back-patch the additional assertions I proposed at [1]. > I'm kind of leaning to committing this as shown and back-patching > the patch at [1], but certainly a case could be made in the other > direction. Thoughts? After further thought about that I realized that the assertion patch could be kluged in the same way as we did in llvmjit_deform.c, and that that would really be the only safe way to do it pre-v13. Otherwise the assertions would trip in pre-existing databases, which would not be nice. So what I've done is to back-patch the assertions that way, and *not* apply BKI_FORCE_NULL in the back branches. The possible downsides of doing that seem to outweigh the upside of making the catalog state cleaner in new installations. regards, tom lane
В списке pgsql-hackers по дате отправления
От: Dmitry Dolgov
Дата: