public inbox for [email protected]
help / color / mirror / Atom feedFrom: Paul Jungwirth <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: jian he <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: vignesh C <[email protected]>
Subject: Re: SQL:2011 application time
Date: Wed, 5 Feb 2025 10:31:05 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<5f0c25de-2c13-4fb5-a4df-a1e03c43cd14@illuminatedcomputin! g.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On 2/5/25 05:37, Peter Eisentraut wrote:
> On 29.01.25 07:34, Paul Jungwirth wrote:
>> Is it possible to commit an RI_PLAN_NO_ACTION addition and see if that makes the buildfarm
>> failures go away? Here is a proposed patch for that (v48.1). I would understand if this is too
>> questionable a practice---but it would be nice to get sufficient test exposure to see if it makes
>> a difference. Since I still haven't reproduced this locally (despite running continuously for
>> almost a week), it's not an experiment I can do myself. If it *does* make the failures go away,
>> then it suggests there is still some latent problem somewhere.
>
> I'm tempted to give this a try. But the cfbot is currently in a bit of a mess, so I'll wait until
> that is clean again so that we can have a usable baseline to work against.
Okay, thanks! I've been spending some more time on this, but I haven't made much progress.
It's surely not as simple as just oid wrapround. Here is a bpftrace script to show when we change
TransamVariables->nextOid:
BEGIN {
@setnext = 0
}
u:/home/paul/local/bin/postgres:GetNewObjectId {
@newoids[tid] += 1
}
u:/home/paul/local/bin/postgres:SetNextObjectId {
@setnext += 1
}
When I run this during `make installcheck` I get only 29608 total calls to GetNewObjectId, and none
for SetNextObjectId.
I've also been looking at the dynahash code a bit. With gdb I can give two constraint oids a hash
collision, but of course that isn't sufficient, since we memcmp the whole key as well.
Last night I started looking at ri_constraint_cache, which is maybe a little more interesting due to
the syscache invalidation code. A parallel test could cause an invalidation between lines of the
without_overlaps test. Getting the wrong riinfo could make us treat a RESTRICT constraint as NO
ACTION. But I don't see any way for that to happen yet.
I have too much confidence in the Postgres codebase to really expect to find bugs in any of these
places. And yet I don't see how 1772d554b0 could make a RESTRICT test fail, since all its changes
are wrapped in `if (is_no_action)`---except if the RESTRICT constraint is somehow executing the NO
ACTION query by mistake.
Anyway I'll keep at it!
Yours,
--
Paul ~{:-)
[email protected]
view thread (23+ messages) latest in thread
reply
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: SQL:2011 application time
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox