On Tue, Aug 30, 2016 at 3:39 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> 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.)

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.


Fujii Masao

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to