From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-31 10:39:29 |
Message-ID: | CAHGQGwHaJLBXpa2Rr2mqMfmuAGxD8+JHCzjn3Pg6w=xm-C93ug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 31, 2016 at 12:10 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>> I found that pg_xlogdump code for XLOG_GIN_INSERT record with
>> GIN_INSERT_ISLEAF flag has the same issue, i.e.,
>> "unknown action 0" error is thrown for that record.
>> The latest patch fixes this.
>
> Hmm, comparing gin_desc() to ginRedoInsert() makes me think there are more
> problems there than that one. Aren't the references to "payload" wrong
> in all three branches of that "if" construct, not just the middle one?
> I'm inclined to suspect we should restructure this more like
>
> {
> ginxlogInsert *xlrec = (ginxlogInsert *) rec;
> - char *payload = rec + sizeof(ginxlogInsert);
>
> appendStringInfo(buf, "isdata: %c isleaf: %c",
> (xlrec->flags & GIN_INSERT_ISDATA) ? 'T' : 'F',
> (xlrec->flags & GIN_INSERT_ISLEAF) ? 'T' : 'F');
> if (!(xlrec->flags & GIN_INSERT_ISLEAF))
> {
> + char *payload = rec + sizeof(ginxlogInsert);
> BlockNumber leftChildBlkno;
> BlockNumber rightChildBlkno;
>
> leftChildBlkno = BlockIdGetBlockNumber((BlockId) payload);
> payload += sizeof(BlockIdData);
> rightChildBlkno = BlockIdGetBlockNumber((BlockId) payload);
> payload += sizeof(BlockNumber);
> appendStringInfo(buf, " children: %u/%u",
> leftChildBlkno, rightChildBlkno);
> }
> + if (XLogRecHasBlockImage(record, 0))
> + appendStringInfoString(buf, " (full page image)");
> + else
> + {
> + char *payload = XLogRecGetBlockData(record, 0, NULL);
> +
> if (!(xlrec->flags & GIN_INSERT_ISDATA))
> appendStringInfo(buf, " isdelete: %c",
> (((ginxlogInsertEntry *) payload)->isDelete) ? 'T' : 'F');
> ... etc etc ...
If we do this, the extra information like ginxlogInsertEntry->isDelete will
never be reported when the record has FPW. This is OK in terms of REDO
because REDO logic just restores FPW and doesn't see isDelete in that case.
However if gin_desc() was initially implemented to dump any information
contained in WAL record as much as possible even when it had FPW,
we should not do such restructure. Not sure the initial intention for that.
For the purpose of debugging WAL generation code, I think that it's better
to dump even information that REDO logic doesn't use.
BTW, whether the record has FPW or not is reported in other places like
XLogDumpDisplayRecord() and xlog_outrec(). So we can check whether
FPW is contained or not, from the output of pg_xlogdump, even if
gin_desc doesn't report "(full page image)".
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2016-08-31 10:48:29 | Use static inline functions for Float <-> Datum conversions |
Previous Message | Etsuro Fujita | 2016-08-31 09:01:41 | Re: Confusing docs about GetForeignUpperPaths in fdwhandler.sgml |