From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tv@fuzzy.cz>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-committers <pgsql-committers@postgresql.org>
Subject: Re: pgsql: Generational memory allocator
Date: Fri, 24 Nov 2017 20:25:38 -0500
Message-ID: <4618.1511573138@sss.pgh.pa.us> (raw)
In-Reply-To: <16449.1511548313@sss.pgh.pa.us>
References: <E1eHa4J-0006hI-Q8@gemulon.postgresql.org>
<20171123001649.y2nf7422iay6cw3v@alap3.anarazel.de>
<CANP8+jKoT=Pg5W_3FcKiDf+FMrJhFYacxt_g5E0=tkmb5s8M6g@mail.gmail.com>
<c903f275-2150-fa52-64bf-dca7b53ebf8d@fuzzy.cz>
<16449.1511548313@sss.pgh.pa.us>
I wrote:
> For me, this patch fixes the valgrind failures inside generation.c
> itself, but I still see one more in the test_decoding run: ...
> Not sure what to make of this: the stack traces make it look unrelated
> to the GenerationContext changes, but if it's not related, how come
> skink was passing before that patch went in?
I've pushed fixes for everything that I could find wrong in generation.c
(and there was a lot :-(). But I'm still seeing the "invalid read in
SnapBuildProcessNewCid" failure when I run test_decoding under valgrind.
Somebody who has more familiarity with the logical decoding stuff than
I do needs to look into that.
I tried to narrow down exactly which fetch in SnapBuildProcessNewCid was
triggering the failure, with the attached patch. Weirdly, *it does not
fail* with this. I have no explanation for that.
regards, tom lane
Attachments:
[text/x-diff] hack-to-split-up-fetches.patch (1.5K, ../4618.1511573138@sss.pgh.pa.us/2-hack-to-split-up-fetches.patch)
download | inline diff:diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.cindex ad65b98..a48db7e 100644
*** a/src/backend/replication/logical/snapbuild.c
--- b/src/backend/replication/logical/snapbuild.c
*************** SnapBuildProcessNewCid(SnapBuild *builde
*** 770,775 ****
--- 770,781 ----
XLogRecPtr lsn, xl_heap_new_cid *xlrec)
{
CommandId cid;
+ TransactionId top_xid;+ RelFileNode node;+ ItemPointerData tid;+ CommandId cmin;+ CommandId cmax;+ CommandId combocid;
/*
* we only log new_cid's if a catalog tuple was modified, so mark the
*************** SnapBuildProcessNewCid(SnapBuild *builde
*** 777,786 ****
*/
ReorderBufferXidSetCatalogChanges(builder->reorder, xid, lsn);
! ReorderBufferAddNewTupleCids(builder->reorder, xlrec->top_xid, lsn,
! xlrec->target_node, xlrec->target_tid,
! xlrec->cmin, xlrec->cmax,
! xlrec->combocid);
/* figure out new command id */
if (xlrec->cmin != InvalidCommandId &&
--- 783,799 ----
*/
ReorderBufferXidSetCatalogChanges(builder->reorder, xid, lsn);
! top_xid = xlrec->top_xid;
! node = xlrec->target_node;
! tid = xlrec->target_tid;
! cmin = xlrec->cmin;
! cmax = xlrec->cmax;
! combocid = xlrec->combocid;
!
! ReorderBufferAddNewTupleCids(builder->reorder, top_xid, lsn,
! node, tid,
! cmin, cmax,
! combocid);
/* figure out new command id */
if (xlrec->cmin != InvalidCommandId &&
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, tv@fuzzy.cz, simon@2ndquadrant.com
Subject: Re: pgsql: Generational memory allocator
In-Reply-To: <4618.1511573138@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox