| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: GIN logging GIN_SEGMENT_UNMODIFIED actions? |
| Date: | 2016-08-29 18:39:27 |
| Message-ID: | 16009.1472495967@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Fujii Masao <masao(dot)fujii(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rémi Zara | 2016-08-29 18:40:18 | Re: OpenSSL 1.1 breaks configure and more |
| Previous Message | Tom Lane | 2016-08-29 18:27:17 | Re: OpenSSL 1.1 breaks configure and more |