Re: BUG #16219: EvalPlanQualFetchRowMark segfaults on Updates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: julian(dot)schauder(at)gmx(dot)de
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16219: EvalPlanQualFetchRowMark segfaults on Updates
Date: 2020-01-20 16:14:26
Message-ID: 13589.1579536866@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> for a week now (upgrade pg11=>12) we're experiencing a bug that causes
> segfaults on a daily basis.
> I've yet to reproduce this exact behaviour as the querys do not fail all the
> time but rather now-and-then
> when run concurrently. ( ~4 Crashes so far )

Not sure if you realize that the EvalPlanQual stuff is only called when
there's an uncommitted conflicting update on a target row. So the way
I'd try to reproduce something like this is

session 1 session 2

begin;
issue update query;
issue same update query;
commit;

which should take the race-condition issue out of the equation,
since session 2 will certainly be trying to update the same
rows that session 1 did but hasn't yet committed.

There may be other hard-to-reproduce factors at work, of course.
If you can test on a debug build (with --enable-cassert), that'd
help remove a few more variables.

>> earm = 0x5576c7176258
>> erm = 0x24

> Excerpt shows the pointer 0x24 of erm to be uninitialized'ish.

Yeah. If you could do "p *earm" here, that might offer some clues;
I'm wondering if that entire struct has gotten trashed (likely because
somebody freed it too soon).

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-01-20 17:58:29 Re: BUG #16199: pg_restore stuck on interrupts
Previous Message PG Bug reporting form 2020-01-20 14:54:34 BUG #16219: EvalPlanQualFetchRowMark segfaults on Updates