Re: GIN logging GIN_SEGMENT_UNMODIFIED actions? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GIN logging GIN_SEGMENT_UNMODIFIED actions?
Date
Msg-id 16009.1472495967@sss.pgh.pa.us
Whole thread Raw
In response to Re: GIN logging GIN_SEGMENT_UNMODIFIED actions?  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: GIN logging GIN_SEGMENT_UNMODIFIED actions?  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
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.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: OpenSSL 1.1 breaks configure and more
Next
From: Rémi Zara
Date:
Subject: Re: OpenSSL 1.1 breaks configure and more