Re: GIN logging GIN_SEGMENT_UNMODIFIED actions?
От | Fujii Masao |
---|---|
Тема | Re: GIN logging GIN_SEGMENT_UNMODIFIED actions? |
Дата | |
Msg-id | CAHGQGwFUYnqu3jrsfGxcL1PWWRJfqDvViU_0y3P0RBOg9mm5fA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GIN logging GIN_SEGMENT_UNMODIFIED actions? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: GIN logging GIN_SEGMENT_UNMODIFIED actions?
|
Список | pgsql-hackers |
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. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: