Re: logical decoding bug: segfault in ReorderBufferToastReplace()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Дата
Msg-id 19042.1576084263@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Andres Freund <andres@anarazel.de>)
Ответы Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Robert Haas <robertmhaas@gmail.com>)
Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Robert Haas <robertmhaas@gmail.com>)
Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Andres Freund <andres@anarazel.de>)
Re: logical decoding bug: segfault in ReorderBufferToastReplace()  (Andres Freund <andres@anarazel.de>)
Список pgsql-bugs
Andres Freund <andres@anarazel.de> writes:
> This indicates that a toast record was present for that relation,
> despite:
> [ \d that looks like the table isn't wide enough for that ]
> I think we need to see pg_waldump output for the preceding records. That
> might allow us to see why there's a toast record that's being associated
> with this table, despite there not being a toast table.

I don't think you can make that conclusion.  Perhaps the table once
needed a toast table because of some wide column that got dropped;
if so, it'd still have one.  It'd be safer to look at
pg_class.reltoastrelid to verify existence (or not) of the toast relation.

It strikes me that there could easily be cases where a publisher table
has a toast relation and a subscriber's doesn't ... maybe this code
isn't expecting that?

            regards, tom lane



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Memory leak (possibly connected to postgis) leading to server crash
Следующее
От: Robert Haas
Дата:
Сообщение: Re: logical decoding bug: segfault in ReorderBufferToastReplace()