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
Дата:
От: Antonin Houska
Дата:
Сообщение: xl_heap_header alignment?
FAQ