On Fri, Aug 26, 2016 at 11:35 PM, Fujii Masao <masao.fu...@gmail.com> wrote:
> On Tue, May 10, 2016 at 9:57 PM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
>> Hi!
>>
>> On Mon, May 9, 2016 at 10:46 PM, Andres Freund <and...@anarazel.de> wrote:
>>>
>>> trying to debug something I saw the following in pg_xlogdump output:
>>>
>>> rmgr: Gin len (rec/tot): 0/ 274, tx: 0, lsn:
>>> 1C/DF28AEB0, prev 1C/DF289858, desc: VACUUM_DATA_LEAF_PAGE 3 segments: 5
>>> unknown action 0 ???, blkref #0: rel 1663/16384/16435 blk 310982
>>>
>>> note the "segments: 5 unknown action 0 ???" bit. That doesn't seem
>>> right, given:
>>> #define GIN_SEGMENT_UNMODIFIED 0 /* no action (not used in
>>> WAL records) */
>>
>>
>> I've checked GIN code. Have no idea of how such wal record could be
>> generated...
>
> I encountered the same issue when executing the following queries and
> running pg_xlogdump.
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?
BTW, in REDO side, ginRedoVacuumDataLeafPage() uses XLogRecGetBlockData()
to extract ginxlogVacuumDataLeafPage data.
Regards,
--
Fujii Masao
*** a/src/backend/access/rmgrdesc/gindesc.c
--- b/src/backend/access/rmgrdesc/gindesc.c
***************
*** 144,150 **** gin_desc(StringInfo buf, XLogReaderState *record)
break;
case XLOG_GIN_VACUUM_DATA_LEAF_PAGE:
{
! ginxlogVacuumDataLeafPage *xlrec = (ginxlogVacuumDataLeafPage *) rec;
if (XLogRecHasBlockImage(record, 0))
appendStringInfoString(buf, " (full page image)");
--- 144,151 ----
break;
case XLOG_GIN_VACUUM_DATA_LEAF_PAGE:
{
! ginxlogVacuumDataLeafPage *xlrec =
! (ginxlogVacuumDataLeafPage *) XLogRecGetBlockData(record, 0, NULL);
if (XLogRecHasBlockImage(record, 0))
appendStringInfoString(buf, " (full page image)");
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
