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
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 |