Re: pgsql: Generational memory allocator

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tomas Vondra <tv(at)fuzzy(dot)cz>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: Generational memory allocator
Date: 2017-11-25 01:25:38
Message-ID: 4618.1511573138@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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

Attachment Content-Type Size
hack-to-split-up-fetches.patch text/x-diff 1.5 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tomas Vondra 2017-11-25 04:54:18 Re: pgsql: Generational memory allocator
Previous Message Tom Lane 2017-11-25 00:28:32 pgsql: Improve valgrind logic in aset.c, and fix multiple issues in gen