From: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, nathan(at)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: Strange assertion in procarray.c |
Date: | 2024-11-27 02:27:00 |
Message-ID: | CANtu0ojbx6=esP8euQgzD1CN6tigTQvDmupwEmLTHZT=6_yx_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello, Nathan and Michael!
I believe I’ve identified the root cause of the issue. It appears to be
related to the GetNamedDSMSegment and injection_points module.
Here’s how it happens:
* A backend attaches (even locally!) to an injection point, which might get
triggered during resource release (ResourceOwnerRelease).
* Another backend attempts to release the same resource (e.g., by aborting
a transaction) and triggers the injection point.
* This leads to a call to GetNamedDSMSegment, as it’s the first time this
backend interacts with injection points.
* Consequently, an assertion failure occurs in ResourceOwnerEnlarge because
the backend is in the process of releasing all resources.
I’ve attached a reproducer—this version is much simpler for debugging.
So, it looks like we need to provide some option to guarantee
GetNamedDSMSegment called for injection points module.
Any other ideas?
Best regards,
Mikhail.
[0]:
https://github.com/postgres/postgres/commit/8b2bcf3f287c79eaebf724cba57e5ff664b01e06
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Test-to-reproduce-issue-with-crash-caused-by-pass.patch | text/plain | 4.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2024-11-27 03:02:11 | Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE |
Previous Message | Tom Lane | 2024-11-27 02:26:15 | Re: Potential Issue with Redundant Restriction Clauses in get_parameterized_baserel_size for PARTITIONED_REL |