PG Bug reporting form <noreply@postgresql.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