Re: BUG #16129: Segfault in tts_virtual_materialize in logicalreplication worker
От | Ondřej Jirman |
---|---|
Тема | Re: BUG #16129: Segfault in tts_virtual_materialize in logicalreplication worker |
Дата | |
Msg-id | 20191121185844.6qsqhwzzuhu3fpsg@core.my.home обсуждение исходный текст |
Ответ на | Re: BUG #16129: Segfault in tts_virtual_materialize in logicalreplication worker (Ondřej Jirman <ienieghapheoghaiwida@xff.cz>) |
Ответы |
Re: BUG #16129: Segfault in tts_virtual_materialize in logicalreplication worker
|
Список | pgsql-bugs |
On Thu, Nov 21, 2019 at 06:35:55PM +0100, Ondřej Jirman wrote: > One missing piece is what exactly is the contents of the outstanding output from > pgoutput plugin, that the replica crashes on and doesn't apply. Are there any > tools for inspecting the binary output from the pgoutput plugin? Maybe that can > provide a clue. So I've looked at it manually, and the segfaulting transaction doesn't make much sense to me. On primary a row with 37880 byte cover_image was inserted, but pgoutput plugin sends these records: B R - public.videos title cover_image metadata,... U - new row where cover_image tuple doesn't have any data, just a flag ('u') C Which means 'unchanged toast column' according to logical/proto.c Yet cover_image is defined as not null. I guess it's some special handling for VARATT_IS_EXTERNAL_ONDISK. To me this looks like this transaction is assuming data for bytea column cover_image are already replicated from earlier? Maybe it is not though? It's certainly breaking some assumption on the replica, because this is the precise point where segfault happens. regards, o. > regards, > o. > > > regards > > > > -- > > Tomas Vondra http://www.2ndQuadrant.com > > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-bugs по дате отправления: