Fujii Masao <masao.fu...@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.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
