Re: GIN logging GIN_SEGMENT_UNMODIFIED actions?
От | Fujii Masao |
---|---|
Тема | Re: GIN logging GIN_SEGMENT_UNMODIFIED actions? |
Дата | |
Msg-id | CAHGQGwHHX9RHWwpF6XMJATda5-0=52K53KGE19UvHG9Pn=SwDQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GIN logging GIN_SEGMENT_UNMODIFIED actions? (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: GIN logging GIN_SEGMENT_UNMODIFIED actions?
|
Список | pgsql-hackers |
On Tue, Aug 30, 2016 at 3:13 PM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Tue, Aug 30, 2016 at 3:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Fujii Masao <masao.fujii@gmail.com> writes: >>> ISTM that the cause of this issue is that gin_desc() uses XLogRecGetData() to >>> extract ginxlogVacuumDataLeafPage data from XLOG_GIN_VACUUM_DATA_LEAF_PAGE >>> record. Since it's registered by XLogRegisterBufData() in >>> ginVacuumPostingTreeLeaf(), >>> XLogRecGetBlockData() should be used, instead. Patch attached. Thought? >> >> I think we probably have more issues than that. See for example >> https://www.postgresql.org/message-id/flat/20160826072658.15676.7628%40wrigleys.postgresql.org >> >> which clearly shows that the replay logic is seeing something wrong too: >> >> 2016-08-26 06:01:50 UTC FATAL: unexpected GIN leaf action: 0 >> 2016-08-26 06:01:50 UTC CONTEXT: xlog redo Insert item, node: >> 1663/16387/33108 blkno: 6622 isdata: T isleaf: T 3 segments: 2 (add 0 items) >> 0 unknown action 0 ??? >> >> If it were just a matter of gin_desc() being wrong, we'd not have >> gotten such a failure. (Which is not to say that gin_desc() isn't >> wrong; it may well be.) > > Yeah, I got the pg_xlogdump issue while I was trying to reproduce > the above reported problem. Fixing pg_xlogdump would be helpful for > the analysis of that problem. Attached is the updated version of the patch. I found that pg_xlogdump code for XLOG_GIN_INSERT record with GIN_INSERT_ISLEAF flag has the same issue, i.e., "unknown action 0" error is thrown for that record. The latest patch fixes this. Regards, -- Fujii Masao
Вложения
В списке pgsql-hackers по дате отправления: