pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
21+ messages / 5 participants
[nested] [flat]
* BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
@ 2025-09-17 15:08 PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: PG Bug reporting form @ 2025-09-17 15:08 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: feichanghong@qq.com
The following bug has been logged on the website:
Bug reference: 19056
Logged by: Fei Changhong
Email address: feichanghong@qq.com
PostgreSQL version: 18rc1
Operating system: Operating system: centos 8,Kernel version: 5.10.13
Description:
Hi all,
I recently encountered a crash when executing a DELETE on PG18. The issue
can be reproduced on the HEAD branch with the following steps:
session1:
```sql
CREATE TABLE test_hash (
id int,
data text
) PARTITION BY HASH (id);
CREATE TABLE test_hash_0 PARTITION OF test_hash
FOR VALUES WITH (MODULUS 2, REMAINDER 0);
CREATE TABLE test_hash_1 PARTITION OF test_hash
FOR VALUES WITH (MODULUS 2, REMAINDER 1);
insert into test_hash select 1, '1';
begin ;
update test_hash set data = '2';
```
session2:
```sql
set plan_cache_mode to force_generic_plan;
prepare s as delete from test_hash where id = $1;
execute s(1);
```
session1:
```sql
commit;
```
The following stack trace was observed:
```
(gdb) bt 10
#0 0x000000000079de74 in list_nth (list=0x0, n=0) at
../../../src/include/nodes/pg_list.h:301
#1 0x00000000007a0eeb in ExecInitPartitionExecPruning (planstate=0x1884f40,
n_total_subplans=2, part_prune_index=0,
relids=0x18720a8, initially_valid_subplans=0x7ffc6d56b198) at
execPartition.c:1891
#2 0x00000000007bc8d0 in ExecInitAppend (node=0x1863bb0, estate=0x1884ca0,
eflags=0) at nodeAppend.c:147
#3 0x00000000007a2300 in ExecInitNode (node=0x1863bb0, estate=0x1884ca0,
eflags=0) at execProcnode.c:182
#4 0x000000000079af67 in EvalPlanQualStart (epqstate=0x186adf8,
planTree=0x1863bb0) at execMain.c:3143
#5 0x000000000079a8ab in EvalPlanQualBegin (epqstate=0x186adf8) at
execMain.c:2930
#6 0x00000000007e18e1 in ExecDelete (context=0x7ffc6d56b480,
resultRelInfo=0x186af20, tupleid=0x7ffc6d56b402,
oldtuple=0x0, processReturning=true, changingPart=false, canSetTag=true,
tmresult=0x0, tupleDeleted=0x0,
epqreturnslot=0x0) at nodeModifyTable.c:1709
#7 0x00000000007e61e2 in ExecModifyTable (pstate=0x186ad10) at
nodeModifyTable.c:4518
#8 0x00000000007a29a1 in ExecProcNodeFirst (node=0x186ad10) at
execProcnode.c:469
#9 0x00000000007959cb in ExecProcNode (node=0x186ad10) at
../../../src/include/executor/executor.h:316
```
Likely cause: EvalPlanQualStart creates a new EState without setting
es_part_prune_infos.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
@ 2025-09-17 21:43 ` David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: David Rowley @ 2025-09-17 21:43 UTC (permalink / raw)
To: feichanghong@qq.com, pgsql-bugs@lists.postgresql.org, Amit Langote <amitlangote09@gmail.com>
On Thu, 18 Sept 2025 at 03:25, PG Bug reporting form
<noreply@postgresql.org> wrote:
> I recently encountered a crash when executing a DELETE on PG18. The issue
> can be reproduced on the HEAD branch with the following steps:
Thanks for the report.
The first bad commit is:
commit bb3ec16e14ded1d23a46d3c7e623a965164fa124
Author: Amit Langote <amitlan@postgresql.org>
Date: Thu Jan 30 11:57:32 2025 +0900
Move PartitionPruneInfo out of plan nodes into PlannedStmt
David
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
@ 2025-09-17 22:32 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: David Rowley @ 2025-09-17 22:32 UTC (permalink / raw)
To: feichanghong@qq.com, pgsql-bugs@lists.postgresql.org, Amit Langote <amitlangote09@gmail.com>
On Thu, 18 Sept 2025 at 09:43, David Rowley <dgrowleyml@gmail.com> wrote:
> The first bad commit is:
>
> commit bb3ec16e14ded1d23a46d3c7e623a965164fa124
> Author: Amit Langote <amitlan@postgresql.org>
> Date: Thu Jan 30 11:57:32 2025 +0900
>
> Move PartitionPruneInfo out of plan nodes into PlannedStmt
I think the attached is the correct fix. I also wonder if it's worth
an isolation test to exercise this code.
David
Attachments:
[application/octet-stream] 19056_fix.patch (916B, ../../CAApHDvpNWPQU790AKFsMpSj4-fK1k7K78jigtPAXneiVT1_BBA@mail.gmail.com/2-19056_fix.patch)
download | inline diff:
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index ff12e2e1364..831c55ce787 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -3084,6 +3084,15 @@ EvalPlanQualStart(EPQState *epqstate, Plan *planTree)
*/
rcestate->es_unpruned_relids = parentestate->es_unpruned_relids;
+ /*
+ * Also make the PartitionPruneInfo and the results of pruning available.
+ * These need to match exactly so that we initialize all the same Append
+ * and MergeAppend subplans as the parent did.
+ */
+ rcestate->es_part_prune_infos = parentestate->es_part_prune_infos;
+ rcestate->es_part_prune_states = parentestate->es_part_prune_states;
+ rcestate->es_part_prune_results = parentestate->es_part_prune_results;
+
/*
* Initialize private state information for each SubPlan. We must do this
* before running ExecInitNode on the main query tree, since
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
@ 2025-09-18 01:33 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
0 siblings, 1 reply; 21+ messages in thread
From: Amit Langote @ 2025-09-18 01:33 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: feichanghong@qq.com; pgsql-bugs@lists.postgresql.org
On Thu, Sep 18, 2025 at 7:32 AM David Rowley <dgrowleyml@gmail.com> wrote:
> On Thu, 18 Sept 2025 at 09:43, David Rowley <dgrowleyml@gmail.com> wrote:
> > The first bad commit is:
> >
> > commit bb3ec16e14ded1d23a46d3c7e623a965164fa124
> > Author: Amit Langote <amitlan@postgresql.org>
> > Date: Thu Jan 30 11:57:32 2025 +0900
> >
> > Move PartitionPruneInfo out of plan nodes into PlannedStmt
>
> I think the attached is the correct fix. I also wonder if it's worth
> an isolation test to exercise this code.
Thanks for the patch, David, and for the report, Fei. I indeed forgot
to update EvalPlanQualStart() in that commit.
I agree about adding an isolation test, which I have done in the
attached updated patch.
--
Thanks, Amit Langote
Attachments:
[application/octet-stream] v2-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch (4.6K, ../../CA+HiwqG7Heq9WuzwtNixdqYEOAgcEgmx7dQGkGE0Bwt3v0EBXw@mail.gmail.com/2-v2-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch)
download | inline diff:
From 5946426e7eb7d5fb77b3562f23fc287af5f65eb2 Mon Sep 17 00:00:00 2001
From: Amit Langote <amitlan@postgresql.org>
Date: Thu, 18 Sep 2025 10:09:47 +0900
Subject: [PATCH v2] Fix EPQ crash from missing partition pruning state in
EState
Commit bb3ec16e14 moved partition pruning metadata into PlannedStmt.
At executor startup this metadata is used to initialize the EState
fields es_part_prune_infos, es_part_prune_states, and
es_part_prune_results. EvalPlanQualStart() failed to copy those
fields into the child EState, causing NULL dereference when Append
ran partition pruning during a recheck. This can occur with DELETE
or UPDATE on partitioned tables that use runtime pruning, e.g. with
generic plans.
Fix by copying all partition pruning state into the EPQ estate.
Add an isolation test that reproduces the crash with concurrent
UPDATE and DELETE on a partitioned table, where the DELETE session
hits the crash during its EPQ recheck after the UPDATE commits.
Bug: #19056
Reported-by: Fei Changhong <feichanghong@qq.com>
Diagnozed-by: Fei Changhong <feichanghong@qq.com>
Author: David Rowley <dgrowleyml@gmail.com>
Co-authored-by: Amit Langote <amitlangote09@gmail.com>
Discussion: https://postgr.es/m/19056-a677cef9b54d76a0%40postgresql.org
---
src/backend/executor/execMain.c | 9 +++++++++
.../isolation/expected/eval-plan-qual.out | 18 +++++++++++++++++-
src/test/isolation/specs/eval-plan-qual.spec | 19 +++++++++++++++++++
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index ff12e2e1364..831c55ce787 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -3084,6 +3084,15 @@ EvalPlanQualStart(EPQState *epqstate, Plan *planTree)
*/
rcestate->es_unpruned_relids = parentestate->es_unpruned_relids;
+ /*
+ * Also make the PartitionPruneInfo and the results of pruning available.
+ * These need to match exactly so that we initialize all the same Append
+ * and MergeAppend subplans as the parent did.
+ */
+ rcestate->es_part_prune_infos = parentestate->es_part_prune_infos;
+ rcestate->es_part_prune_states = parentestate->es_part_prune_states;
+ rcestate->es_part_prune_results = parentestate->es_part_prune_results;
+
/*
* Initialize private state information for each SubPlan. We must do this
* before running ExecInitNode on the main query tree, since
diff --git a/src/test/isolation/expected/eval-plan-qual.out b/src/test/isolation/expected/eval-plan-qual.out
index 032d4208d51..33c3f7c0ed4 100644
--- a/src/test/isolation/expected/eval-plan-qual.out
+++ b/src/test/isolation/expected/eval-plan-qual.out
@@ -1,4 +1,4 @@
-Parsed test spec with 3 sessions
+Parsed test spec with 5 sessions
starting permutation: wx1 wx2 c1 c2 read
step wx1: UPDATE accounts SET balance = balance - 200 WHERE accountid = 'checking' RETURNING balance;
@@ -1363,3 +1363,19 @@ step sysmerge2:
step c1: COMMIT;
step sysmerge2: <... completed>
step c2: COMMIT;
+
+starting permutation: s1pp1 s1pp2 s2pp1 s2pp2 s2pp3 s1pp3 s2pp4 s2pp5
+step s1pp1: BEGIN;
+step s1pp2: UPDATE another_parttbl SET b = b + 1 WHERE a = 1;
+step s2pp1: SET plan_cache_mode TO force_generic_plan;
+step s2pp2: PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1;
+step s2pp3: EXECUTE epd(1); <waiting ...>
+step s1pp3: COMMIT;
+step s2pp3: <... completed>
+step s2pp4: SELECT count(*) FROM another_parttbl;
+count
+-----
+ 0
+(1 row)
+
+step s2pp5: DEALLOCATE epd;
diff --git a/src/test/isolation/specs/eval-plan-qual.spec b/src/test/isolation/specs/eval-plan-qual.spec
index 07307e623e4..0b973778715 100644
--- a/src/test/isolation/specs/eval-plan-qual.spec
+++ b/src/test/isolation/specs/eval-plan-qual.spec
@@ -334,6 +334,22 @@ step multireadwcte {
teardown { COMMIT; }
+# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
+# Bug #19056
+session s4
+
+step s1pp1 { BEGIN; }
+step s1pp2 { UPDATE another_parttbl SET b = b + 1 WHERE a = 1; }
+step s1pp3 { COMMIT; }
+
+session s5
+
+step s2pp1 { SET plan_cache_mode TO force_generic_plan; }
+step s2pp2 { PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1; }
+step s2pp3 { EXECUTE epd(1); }
+step s2pp4 { SELECT count(*) FROM another_parttbl; }
+step s2pp5 { DEALLOCATE epd;}
+
# test that normal update follows update chains, and reverifies quals
permutation wx1 wx2 c1 c2 read
permutation wy1 wy2 c1 c2 read
@@ -401,3 +417,6 @@ permutation simplepartupdate_noroute complexpartupdate_doesnt_route c1 c2 read_p
permutation sys1 sysupd2 c1 c2
permutation sys1 sysmerge2 c1 c2
+
+# EState.es_part_prune_infos bug #19056
+permutation s1pp1 s1pp2 s2pp1 s2pp2 s2pp3 s1pp3 s2pp4 s2pp5
--
2.43.0
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
@ 2025-09-18 01:58 ` feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: feichanghong @ 2025-09-18 01:58 UTC (permalink / raw)
To: Amit Langote <amitlangote09@gmail.com>; +Cc: David Rowley <dgrowleyml@gmail.com>; pgsql-bugs@lists.postgresql.org
> On Sep 18, 2025, at 09:33, Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Sep 18, 2025 at 7:32 AM David Rowley <dgrowleyml@gmail.com> wrote:
>> On Thu, 18 Sept 2025 at 09:43, David Rowley <dgrowleyml@gmail.com> wrote:
>>> The first bad commit is:
>>>
>>> commit bb3ec16e14ded1d23a46d3c7e623a965164fa124
>>> Author: Amit Langote <amitlan@postgresql.org>
>>> Date: Thu Jan 30 11:57:32 2025 +0900
>>>
>>> Move PartitionPruneInfo out of plan nodes into PlannedStmt
>>
>> I think the attached is the correct fix. I also wonder if it's worth
>> an isolation test to exercise this code.
>
> Thanks for the patch, David, and for the report, Fei. I indeed forgot
> to update EvalPlanQualStart() in that commit.
>
> I agree about adding an isolation test, which I have done in the
> attached updated patch.
Thanks David and Amit for the patch. It looks OK to me, and isolation
testing confirms the issue. Also, should s1ppx and s2ppx in the case be
renamed to s4ppx and s5ppx?
Best Regards,
Fei Changhong
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
@ 2025-09-18 03:10 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Amit Langote @ 2025-09-18 03:10 UTC (permalink / raw)
To: feichanghong <feichanghong@qq.com>; +Cc: David Rowley <dgrowleyml@gmail.com>; pgsql-bugs@lists.postgresql.org
On Thu, Sep 18, 2025 at 10:58 feichanghong <feichanghong@qq.com> wrote:
>
>
> On Sep 18, 2025, at 09:33, Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Sep 18, 2025 at 7:32 AM David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Thu, 18 Sept 2025 at 09:43, David Rowley <dgrowleyml@gmail.com> wrote:
>
> The first bad commit is:
>
> commit bb3ec16e14ded1d23a46d3c7e623a965164fa124
> Author: Amit Langote <amitlan@postgresql.org>
> Date: Thu Jan 30 11:57:32 2025 +0900
>
> Move PartitionPruneInfo out of plan nodes into PlannedStmt
>
>
> I think the attached is the correct fix. I also wonder if it's worth
> an isolation test to exercise this code.
>
>
> Thanks for the patch, David, and for the report, Fei. I indeed forgot
> to update EvalPlanQualStart() in that commit.
>
> I agree about adding an isolation test, which I have done in the
> attached updated patch.
>
>
> Thanks David and Amit for the patch. It looks OK to me, and isolation
> testing confirms the issue. Also, should s1ppx and s2ppx in the case be
> renamed to s4ppx and s5ppx?
>
Good catch, you are right, will fix. Thanks.
>
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
@ 2025-09-18 03:37 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Amit Langote @ 2025-09-18 03:37 UTC (permalink / raw)
To: feichanghong <feichanghong@qq.com>; +Cc: David Rowley <dgrowleyml@gmail.com>; pgsql-bugs@lists.postgresql.org
On Thu, Sep 18, 2025 at 12:10 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Thu, Sep 18, 2025 at 10:58 feichanghong <feichanghong@qq.com> wrote:
>> On Sep 18, 2025, at 09:33, Amit Langote <amitlangote09@gmail.com> wrote:
>> On Thu, Sep 18, 2025 at 7:32 AM David Rowley <dgrowleyml@gmail.com> wrote:
>> On Thu, 18 Sept 2025 at 09:43, David Rowley <dgrowleyml@gmail.com> wrote:
>>
>> The first bad commit is:
>>
>> commit bb3ec16e14ded1d23a46d3c7e623a965164fa124
>> Author: Amit Langote <amitlan@postgresql.org>
>> Date: Thu Jan 30 11:57:32 2025 +0900
>>
>> Move PartitionPruneInfo out of plan nodes into PlannedStmt
>>
>> I think the attached is the correct fix. I also wonder if it's worth
>> an isolation test to exercise this code.
>>
>> Thanks for the patch, David, and for the report, Fei. I indeed forgot
>> to update EvalPlanQualStart() in that commit.
>>
>> I agree about adding an isolation test, which I have done in the
>> attached updated patch.
>>
>> Thanks David and Amit for the patch. It looks OK to me, and isolation
>> testing confirms the issue. Also, should s1ppx and s2ppx in the case be
>> renamed to s4ppx and s5ppx?
>
> Good catch, you are right, will fix. Thanks.
Fixed. Will push this barring objections.
--
Thanks, Amit Langote
Attachments:
[application/octet-stream] v3-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch (4.6K, ../../CA+HiwqGzUmLfMU3zoZWN2U31gsY57zULzds8MoX2uocd1yu_hg@mail.gmail.com/2-v3-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch)
download | inline diff:
From 71e12c2c96b38c18a82f69ccf6be79ab72c8eb46 Mon Sep 17 00:00:00 2001
From: Amit Langote <amitlan@postgresql.org>
Date: Thu, 18 Sep 2025 10:09:47 +0900
Subject: [PATCH v3] Fix EPQ crash from missing partition pruning state in
EState
Commit bb3ec16e14 moved partition pruning metadata into PlannedStmt.
At executor startup this metadata is used to initialize the EState
fields es_part_prune_infos, es_part_prune_states, and
es_part_prune_results. EvalPlanQualStart() failed to copy those
fields into the child EState, causing NULL dereference when Append
ran partition pruning during a recheck. This can occur with DELETE
or UPDATE on partitioned tables that use runtime pruning, e.g. with
generic plans.
Fix by copying all partition pruning state into the EPQ estate.
Add an isolation test that reproduces the crash with concurrent
UPDATE and DELETE on a partitioned table, where the DELETE session
hits the crash during its EPQ recheck after the UPDATE commits.
Bug: #19056
Reported-by: Fei Changhong <feichanghong@qq.com>
Diagnozed-by: Fei Changhong <feichanghong@qq.com>
Author: David Rowley <dgrowleyml@gmail.com>
Co-authored-by: Amit Langote <amitlangote09@gmail.com>
Discussion: https://postgr.es/m/19056-a677cef9b54d76a0%40postgresql.org
---
src/backend/executor/execMain.c | 9 +++++++++
.../isolation/expected/eval-plan-qual.out | 18 +++++++++++++++++-
src/test/isolation/specs/eval-plan-qual.spec | 19 +++++++++++++++++++
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index ff12e2e1364..831c55ce787 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -3084,6 +3084,15 @@ EvalPlanQualStart(EPQState *epqstate, Plan *planTree)
*/
rcestate->es_unpruned_relids = parentestate->es_unpruned_relids;
+ /*
+ * Also make the PartitionPruneInfo and the results of pruning available.
+ * These need to match exactly so that we initialize all the same Append
+ * and MergeAppend subplans as the parent did.
+ */
+ rcestate->es_part_prune_infos = parentestate->es_part_prune_infos;
+ rcestate->es_part_prune_states = parentestate->es_part_prune_states;
+ rcestate->es_part_prune_results = parentestate->es_part_prune_results;
+
/*
* Initialize private state information for each SubPlan. We must do this
* before running ExecInitNode on the main query tree, since
diff --git a/src/test/isolation/expected/eval-plan-qual.out b/src/test/isolation/expected/eval-plan-qual.out
index 3d31d0f84e5..485cf0eb912 100644
--- a/src/test/isolation/expected/eval-plan-qual.out
+++ b/src/test/isolation/expected/eval-plan-qual.out
@@ -1,4 +1,4 @@
-Parsed test spec with 3 sessions
+Parsed test spec with 5 sessions
starting permutation: wx1 wx2 c1 c2 read
step wx1: UPDATE accounts SET balance = balance - 200 WHERE accountid = 'checking' RETURNING balance;
@@ -1457,3 +1457,19 @@ step sysmerge2:
step c1: COMMIT;
step sysmerge2: <... completed>
step c2: COMMIT;
+
+starting permutation: s4pp1 s4pp2 s5pp1 s5pp2 s5pp3 s4pp3 s5pp4 s5pp5
+step s4pp1: BEGIN;
+step s4pp2: UPDATE another_parttbl SET b = b + 1 WHERE a = 1;
+step s5pp1: SET plan_cache_mode TO force_generic_plan;
+step s5pp2: PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1;
+step s5pp3: EXECUTE epd(1); <waiting ...>
+step s4pp3: COMMIT;
+step s5pp3: <... completed>
+step s5pp4: SELECT count(*) FROM another_parttbl;
+count
+-----
+ 0
+(1 row)
+
+step s5pp5: DEALLOCATE epd;
diff --git a/src/test/isolation/specs/eval-plan-qual.spec b/src/test/isolation/specs/eval-plan-qual.spec
index c6eee685586..f1de2397771 100644
--- a/src/test/isolation/specs/eval-plan-qual.spec
+++ b/src/test/isolation/specs/eval-plan-qual.spec
@@ -343,6 +343,22 @@ step multireadwcte {
teardown { COMMIT; }
+# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
+# Bug #19056
+session s4
+
+step s4pp1 { BEGIN; }
+step s4pp2 { UPDATE another_parttbl SET b = b + 1 WHERE a = 1; }
+step s4pp3 { COMMIT; }
+
+session s5
+
+step s5pp1 { SET plan_cache_mode TO force_generic_plan; }
+step s5pp2 { PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1; }
+step s5pp3 { EXECUTE epd(1); }
+step s5pp4 { SELECT count(*) FROM another_parttbl; }
+step s5pp5 { DEALLOCATE epd;}
+
# test that normal update follows update chains, and reverifies quals
permutation wx1 wx2 c1 c2 read
permutation wy1 wy2 c1 c2 read
@@ -415,3 +431,6 @@ permutation simplepartupdate_noroute complexpartupdate_doesnt_route c1 c2 read_p
permutation sys1 sysupd2 c1 c2
permutation sys1 sysmerge2 c1 c2
+
+# EState.es_part_prune_infos bug #19056
+permutation s4pp1 s4pp2 s5pp1 s5pp2 s5pp3 s4pp3 s5pp4 s5pp5
--
2.43.0
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
@ 2025-09-18 03:47 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 21+ messages in thread
From: David Rowley @ 2025-09-18 03:47 UTC (permalink / raw)
To: Amit Langote <amitlangote09@gmail.com>; +Cc: feichanghong <feichanghong@qq.com>; pgsql-bugs@lists.postgresql.org
On Thu, 18 Sept 2025 at 15:37, Amit Langote <amitlangote09@gmail.com> wrote:
> Fixed. Will push this barring objections.
Thanks for adding the test case.
> +# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
> +# Bug #19056
I don't think it's that useful to note down the bug number that caused
that test to be added. I think it'd be better to write something like:
"Exercise run-time partition pruning code in an EPQ plan"
If someone really wants to know why the test was added, git blame
linking back to the discussion in the commit message is the normal
workflow.
David
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
@ 2025-09-18 04:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:19 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:56 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
0 siblings, 2 replies; 21+ messages in thread
From: Tom Lane @ 2025-09-18 04:11 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Amit Langote <amitlangote09@gmail.com>; feichanghong <feichanghong@qq.com>; pgsql-bugs@lists.postgresql.org
David Rowley <dgrowleyml@gmail.com> writes:
> On Thu, 18 Sept 2025 at 15:37, Amit Langote <amitlangote09@gmail.com> wrote:
>> +# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
>> +# Bug #19056
> I don't think it's that useful to note down the bug number that caused
> that test to be added.
We're inconsistent about whether we do that or not, but it's
far from un-heard-of. I just today pushed a patch in which
I did mention the bug# in the test case [1], and I did so
mostly because the adjacent test case had a similar comment.
So I see no reason to object to Amit's usage.
> I think it'd be better to write something like:
> "Exercise run-time partition pruning code in an EPQ plan"
Not expressing an opinion about whether that's better or
worse than Amit's lede.
regards, tom lane
[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b0cc0a71e0a0a760f54c72edb8cd000e4...
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-09-18 04:19 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:29 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
1 sibling, 1 reply; 21+ messages in thread
From: David Rowley @ 2025-09-18 04:19 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Amit Langote <amitlangote09@gmail.com>; feichanghong <feichanghong@qq.com>; pgsql-bugs@lists.postgresql.org
On Thu, 18 Sept 2025 at 16:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > I don't think it's that useful to note down the bug number that caused
> > that test to be added.
>
> We're inconsistent about whether we do that or not, but it's
> far from un-heard-of. I just today pushed a patch in which
> I did mention the bug# in the test case [1], and I did so
> mostly because the adjacent test case had a similar comment.
> So I see no reason to object to Amit's usage.
The issue was introduced in v18 dev cycle, so it's never been a
problem in any production build of Postgres. I could get more on board
with an argument for noting these down if it were some long-standing
well known issue that had been around for several years which we
debated how to fix, and finally did. This isn't that, so IMO, noting
down the bug number is pretty pointless.
David
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:19 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
@ 2025-09-18 04:29 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:38 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 21+ messages in thread
From: David Rowley @ 2025-09-18 04:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Amit Langote <amitlangote09@gmail.com>; feichanghong <feichanghong@qq.com>; pgsql-bugs@lists.postgresql.org
On Thu, 18 Sept 2025 at 16:19, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Thu, 18 Sept 2025 at 16:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > We're inconsistent about whether we do that or not, but it's
> > far from un-heard-of. I just today pushed a patch in which
> > I did mention the bug# in the test case [1], and I did so
> > mostly because the adjacent test case had a similar comment.
> > So I see no reason to object to Amit's usage.
>
> The issue was introduced in v18 dev cycle, so it's never been a
> problem in any production build of Postgres. I could get more on board
> with an argument for noting these down if it were some long-standing
> well known issue that had been around for several years which we
> debated how to fix, and finally did. This isn't that, so IMO, noting
> down the bug number is pretty pointless.
Just further to that, while I'm on a rant. It's just not a
sustainable practice to note down the bug numbers. If we did that for
every fix the code and tests would be strewn with random and pretty
meaningless bug numbers. It wouldn't inspire much confidence to the
casual reader of the code either as it would appear mostly to be a
patchwork of fixes. We do have a reputation for good quality. I don't
think we need to put up signs anywhere that indicate mistakes once
existed here, especially for ones that existed in no released version
of PostgreSQL.
David
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:19 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:29 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
@ 2025-09-18 04:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 05:15 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Tom Lane @ 2025-09-18 04:38 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Amit Langote <amitlangote09@gmail.com>; feichanghong <feichanghong@qq.com>; pgsql-bugs@lists.postgresql.org
David Rowley <dgrowleyml@gmail.com> writes:
> ... I don't
> think we need to put up signs anywhere that indicate mistakes once
> existed here, especially for ones that existed in no released version
> of PostgreSQL.
I'm a bit bemused by that viewpoint. There's an enormous fraction of
our test suite that is exactly memorializing bugs that once existed.
Maybe there is some reason to distinguish bugs that never made it
into an official release, but that seems rather weak to me.
regards, tom lane
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:19 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:29 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:38 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-09-18 05:15 ` David Rowley <dgrowleyml@gmail.com>
0 siblings, 0 replies; 21+ messages in thread
From: David Rowley @ 2025-09-18 05:15 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Amit Langote <amitlangote09@gmail.com>; feichanghong <feichanghong@qq.com>; pgsql-bugs@lists.postgresql.org
On Thu, 18 Sept 2025 at 16:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > ... I don't
> > think we need to put up signs anywhere that indicate mistakes once
> > existed here, especially for ones that existed in no released version
> > of PostgreSQL.
>
> I'm a bit bemused by that viewpoint. There's an enormous fraction of
> our test suite that is exactly memorializing bugs that once existed.
> Maybe there is some reason to distinguish bugs that never made it
> into an official release, but that seems rather weak to me.
Not intending to sound nasty here, but if you're going to convince me
that I'm off track in my line of thought, it's going to have to be
something more convincing than "I just did this today mostly because I
copied an existing adjacent test case".
In my view, the only sense in writing down bug numbers in tests or
code is if there's some chance that we might get tricked into putting
it back the broken way again. Otherwise they just act as tombstones to
the should-be-forgotten past. It's hard to imagine someone being
convinced to rebreak this issue and delete Amit's new test.
Segfaulting is clearly wrong behaviour. Nobody will be convinced
otherwise.
David
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-09-18 04:56 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:09 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
1 sibling, 1 reply; 21+ messages in thread
From: Amit Langote @ 2025-09-18 04:56 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: David Rowley <dgrowleyml@gmail.com>; feichanghong <feichanghong@qq.com>; pgsql-bugs@lists.postgresql.org
On Thu, Sep 18, 2025 at 1:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > On Thu, 18 Sept 2025 at 15:37, Amit Langote <amitlangote09@gmail.com> wrote:
> >> +# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
> >> +# Bug #19056
>
> > I don't think it's that useful to note down the bug number that caused
> > that test to be added.
>
> We're inconsistent about whether we do that or not, but it's
> far from un-heard-of. I just today pushed a patch in which
> I did mention the bug# in the test case [1], and I did so
> mostly because the adjacent test case had a similar comment.
> So I see no reason to object to Amit's usage.
I was just mimicking a few other "cf bug #" mentions in
eval-plan-qual.spec, but I'm fine to take it out if we'd prefer to
reduce that. Git blame is enough.
> > I think it'd be better to write something like:
> > "Exercise run-time partition pruning code in an EPQ plan"
>
> Not expressing an opinion about whether that's better or
> worse than Amit's lede.
What I added is:
# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
I'm fine to change the comment to David's suggestion since that makes
the test description less narrowly tied to one fix of one specific
issue in that path.
--
Thanks, Amit Langote
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:56 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
@ 2025-09-18 06:09 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:15 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
0 siblings, 1 reply; 21+ messages in thread
From: Amit Langote @ 2025-09-18 06:09 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: David Rowley <dgrowleyml@gmail.com>; feichanghong <feichanghong@qq.com>; pgsql-bugs@lists.postgresql.org
On Thu, Sep 18, 2025 at 1:56 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Thu, Sep 18, 2025 at 1:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > David Rowley <dgrowleyml@gmail.com> writes:
> > > On Thu, 18 Sept 2025 at 15:37, Amit Langote <amitlangote09@gmail.com> wrote:
> > >> +# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
> > >> +# Bug #19056
> >
> > > I don't think it's that useful to note down the bug number that caused
> > > that test to be added.
> >
> > We're inconsistent about whether we do that or not, but it's
> > far from un-heard-of. I just today pushed a patch in which
> > I did mention the bug# in the test case [1], and I did so
> > mostly because the adjacent test case had a similar comment.
> > So I see no reason to object to Amit's usage.
>
> I was just mimicking a few other "cf bug #" mentions in
> eval-plan-qual.spec, but I'm fine to take it out if we'd prefer to
> reduce that. Git blame is enough.
>
> > > I think it'd be better to write something like:
> > > "Exercise run-time partition pruning code in an EPQ plan"
> >
> > Not expressing an opinion about whether that's better or
> > worse than Amit's lede.
>
> What I added is:
>
> # Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
>
> I'm fine to change the comment to David's suggestion since that makes
> the test description less narrowly tied to one fix of one specific
> issue in that path.
Patch updated.
--
Thanks, Amit Langote
Attachments:
[application/octet-stream] v4-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch (4.6K, ../../CA+HiwqGb-B-5iBNh0eTVe9OgbZFTQi-jnErqN1LLq+W9MADdoA@mail.gmail.com/2-v4-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch)
download | inline diff:
From 9fd9cc6bb0f5c03f062e5a3b89e66142e685d44a Mon Sep 17 00:00:00 2001
From: Amit Langote <amitlan@postgresql.org>
Date: Thu, 18 Sep 2025 15:00:21 +0900
Subject: [PATCH v4] Fix EPQ crash from missing partition pruning state in
EState
Commit bb3ec16e14 moved partition pruning metadata into PlannedStmt.
At executor startup this metadata is used to initialize the EState
fields es_part_prune_infos, es_part_prune_states, and
es_part_prune_results. EvalPlanQualStart() failed to copy those
fields into the child EState, causing NULL dereference when Append
ran partition pruning during a recheck. This can occur with DELETE
or UPDATE on partitioned tables that use runtime pruning, e.g. with
generic plans.
Fix by copying all partition pruning state into the EPQ estate.
Add an isolation test that reproduces the crash with concurrent
UPDATE and DELETE on a partitioned table, where the DELETE session
hits the crash during its EPQ recheck after the UPDATE commits.
Bug: #19056
Reported-by: Fei Changhong <feichanghong@qq.com>
Diagnozed-by: Fei Changhong <feichanghong@qq.com>
Author: David Rowley <dgrowleyml@gmail.com>
Co-authored-by: Amit Langote <amitlangote09@gmail.com>
Discussion: https://postgr.es/m/19056-a677cef9b54d76a0%40postgresql.org
---
src/backend/executor/execMain.c | 9 +++++++++
src/test/isolation/expected/eval-plan-qual.out | 18 +++++++++++++++++-
src/test/isolation/specs/eval-plan-qual.spec | 18 ++++++++++++++++++
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index ff12e2e1364..831c55ce787 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -3084,6 +3084,15 @@ EvalPlanQualStart(EPQState *epqstate, Plan *planTree)
*/
rcestate->es_unpruned_relids = parentestate->es_unpruned_relids;
+ /*
+ * Also make the PartitionPruneInfo and the results of pruning available.
+ * These need to match exactly so that we initialize all the same Append
+ * and MergeAppend subplans as the parent did.
+ */
+ rcestate->es_part_prune_infos = parentestate->es_part_prune_infos;
+ rcestate->es_part_prune_states = parentestate->es_part_prune_states;
+ rcestate->es_part_prune_results = parentestate->es_part_prune_results;
+
/*
* Initialize private state information for each SubPlan. We must do this
* before running ExecInitNode on the main query tree, since
diff --git a/src/test/isolation/expected/eval-plan-qual.out b/src/test/isolation/expected/eval-plan-qual.out
index 3d31d0f84e5..485cf0eb912 100644
--- a/src/test/isolation/expected/eval-plan-qual.out
+++ b/src/test/isolation/expected/eval-plan-qual.out
@@ -1,4 +1,4 @@
-Parsed test spec with 3 sessions
+Parsed test spec with 5 sessions
starting permutation: wx1 wx2 c1 c2 read
step wx1: UPDATE accounts SET balance = balance - 200 WHERE accountid = 'checking' RETURNING balance;
@@ -1457,3 +1457,19 @@ step sysmerge2:
step c1: COMMIT;
step sysmerge2: <... completed>
step c2: COMMIT;
+
+starting permutation: s4pp1 s4pp2 s5pp1 s5pp2 s5pp3 s4pp3 s5pp4 s5pp5
+step s4pp1: BEGIN;
+step s4pp2: UPDATE another_parttbl SET b = b + 1 WHERE a = 1;
+step s5pp1: SET plan_cache_mode TO force_generic_plan;
+step s5pp2: PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1;
+step s5pp3: EXECUTE epd(1); <waiting ...>
+step s4pp3: COMMIT;
+step s5pp3: <... completed>
+step s5pp4: SELECT count(*) FROM another_parttbl;
+count
+-----
+ 0
+(1 row)
+
+step s5pp5: DEALLOCATE epd;
diff --git a/src/test/isolation/specs/eval-plan-qual.spec b/src/test/isolation/specs/eval-plan-qual.spec
index c6eee685586..c69d7e710c4 100644
--- a/src/test/isolation/specs/eval-plan-qual.spec
+++ b/src/test/isolation/specs/eval-plan-qual.spec
@@ -343,6 +343,21 @@ step multireadwcte {
teardown { COMMIT; }
+# Exercise run-time partition pruning code in an EPQ recheck
+session s4
+
+step s4pp1 { BEGIN; }
+step s4pp2 { UPDATE another_parttbl SET b = b + 1 WHERE a = 1; }
+step s4pp3 { COMMIT; }
+
+session s5
+
+step s5pp1 { SET plan_cache_mode TO force_generic_plan; }
+step s5pp2 { PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1; }
+step s5pp3 { EXECUTE epd(1); }
+step s5pp4 { SELECT count(*) FROM another_parttbl; }
+step s5pp5 { DEALLOCATE epd;}
+
# test that normal update follows update chains, and reverifies quals
permutation wx1 wx2 c1 c2 read
permutation wy1 wy2 c1 c2 read
@@ -415,3 +430,6 @@ permutation simplepartupdate_noroute complexpartupdate_doesnt_route c1 c2 read_p
permutation sys1 sysupd2 c1 c2
permutation sys1 sysmerge2 c1 c2
+
+# EState.es_part_prune_infos bug #19056
+permutation s4pp1 s4pp2 s5pp1 s5pp2 s5pp3 s4pp3 s5pp4 s5pp5
--
2.43.0
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:56 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:09 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
@ 2025-09-18 06:15 ` feichanghong <feichanghong@qq.com>
2025-09-18 06:20 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: feichanghong @ 2025-09-18 06:15 UTC (permalink / raw)
To: Amit Langote <amitlangote09@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David Rowley <dgrowleyml@gmail.com>; pgsql-bugs@lists.postgresql.org
> On Sep 18, 2025, at 14:09, Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Sep 18, 2025 at 1:56 PM Amit Langote <amitlangote09@gmail.com <mailto:amitlangote09@gmail.com>> wrote:
>> On Thu, Sep 18, 2025 at 1:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>
>>> David Rowley <dgrowleyml@gmail.com> writes:
>>>> On Thu, 18 Sept 2025 at 15:37, Amit Langote <amitlangote09@gmail.com> wrote:
>>>>> +# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
>>>>> +# Bug #19056
>>>
>>>> I don't think it's that useful to note down the bug number that caused
>>>> that test to be added.
>>>
>>> We're inconsistent about whether we do that or not, but it's
>>> far from un-heard-of. I just today pushed a patch in which
>>> I did mention the bug# in the test case [1], and I did so
>>> mostly because the adjacent test case had a similar comment.
>>> So I see no reason to object to Amit's usage.
>>
>> I was just mimicking a few other "cf bug #" mentions in
>> eval-plan-qual.spec, but I'm fine to take it out if we'd prefer to
>> reduce that. Git blame is enough.
>>
>>>> I think it'd be better to write something like:
>>>> "Exercise run-time partition pruning code in an EPQ plan"
>>>
>>> Not expressing an opinion about whether that's better or
>>> worse than Amit's lede.
>>
>> What I added is:
>>
>> # Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
>>
>> I'm fine to change the comment to David's suggestion since that makes
>> the test description less narrowly tied to one fix of one specific
>> issue in that path.
>
> Patch updated.
> +# EState.es_part_prune_infos bug #19056
There is still bug #19056 here.
Best Regards,
Fei Changhong
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:56 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:09 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:15 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
@ 2025-09-18 06:20 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 07:05 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Amit Langote @ 2025-09-18 06:20 UTC (permalink / raw)
To: feichanghong <feichanghong@qq.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; David Rowley <dgrowleyml@gmail.com>; pgsql-bugs@lists.postgresql.org
On Thu, Sep 18, 2025 at 3:15 PM feichanghong <feichanghong@qq.com> wrote:
> On Sep 18, 2025, at 14:09, Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Sep 18, 2025 at 1:56 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Sep 18, 2025 at 1:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>
> David Rowley <dgrowleyml@gmail.com> writes:
>
> On Thu, 18 Sept 2025 at 15:37, Amit Langote <amitlangote09@gmail.com> wrote:
>
> +# Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
> +# Bug #19056
>
>
> I don't think it's that useful to note down the bug number that caused
> that test to be added.
>
>
> We're inconsistent about whether we do that or not, but it's
> far from un-heard-of. I just today pushed a patch in which
> I did mention the bug# in the test case [1], and I did so
> mostly because the adjacent test case had a similar comment.
> So I see no reason to object to Amit's usage.
>
>
> I was just mimicking a few other "cf bug #" mentions in
> eval-plan-qual.spec, but I'm fine to take it out if we'd prefer to
> reduce that. Git blame is enough.
>
> I think it'd be better to write something like:
> "Exercise run-time partition pruning code in an EPQ plan"
>
>
> Not expressing an opinion about whether that's better or
> worse than Amit's lede.
>
>
> What I added is:
>
> # Test that EState.es_part_prune_infos is properly set in EvalPlanQualStart()
>
> I'm fine to change the comment to David's suggestion since that makes
> the test description less narrowly tied to one fix of one specific
> issue in that path.
>
>
> Patch updated.
>
> +# EState.es_part_prune_infos bug #19056
Oops, coffee deficiency. Updated again.
--
Thanks, Amit Langote
Attachments:
[application/octet-stream] v5-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch (4.6K, ../../CA+HiwqHtVVfzxdbNCHpveHQRGLT_EJ2fSoKc2Z8Dhdxt1Gg+RQ@mail.gmail.com/2-v5-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch)
download | inline diff:
From 38f1673cdfb522e4c0d22c2ca57b34869f711e71 Mon Sep 17 00:00:00 2001
From: Amit Langote <amitlan@postgresql.org>
Date: Thu, 18 Sep 2025 15:00:21 +0900
Subject: [PATCH v5] Fix EPQ crash from missing partition pruning state in
EState
Commit bb3ec16e14 moved partition pruning metadata into PlannedStmt.
At executor startup this metadata is used to initialize the EState
fields es_part_prune_infos, es_part_prune_states, and
es_part_prune_results. EvalPlanQualStart() failed to copy those
fields into the child EState, causing NULL dereference when Append
ran partition pruning during a recheck. This can occur with DELETE
or UPDATE on partitioned tables that use runtime pruning, e.g. with
generic plans.
Fix by copying all partition pruning state into the EPQ estate.
Add an isolation test that reproduces the crash with concurrent
UPDATE and DELETE on a partitioned table, where the DELETE session
hits the crash during its EPQ recheck after the UPDATE commits.
Bug: #19056
Reported-by: Fei Changhong <feichanghong@qq.com>
Diagnozed-by: Fei Changhong <feichanghong@qq.com>
Author: David Rowley <dgrowleyml@gmail.com>
Co-authored-by: Amit Langote <amitlangote09@gmail.com>
Discussion: https://postgr.es/m/19056-a677cef9b54d76a0%40postgresql.org
---
src/backend/executor/execMain.c | 9 +++++++++
src/test/isolation/expected/eval-plan-qual.out | 18 +++++++++++++++++-
src/test/isolation/specs/eval-plan-qual.spec | 18 ++++++++++++++++++
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index ff12e2e1364..831c55ce787 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -3084,6 +3084,15 @@ EvalPlanQualStart(EPQState *epqstate, Plan *planTree)
*/
rcestate->es_unpruned_relids = parentestate->es_unpruned_relids;
+ /*
+ * Also make the PartitionPruneInfo and the results of pruning available.
+ * These need to match exactly so that we initialize all the same Append
+ * and MergeAppend subplans as the parent did.
+ */
+ rcestate->es_part_prune_infos = parentestate->es_part_prune_infos;
+ rcestate->es_part_prune_states = parentestate->es_part_prune_states;
+ rcestate->es_part_prune_results = parentestate->es_part_prune_results;
+
/*
* Initialize private state information for each SubPlan. We must do this
* before running ExecInitNode on the main query tree, since
diff --git a/src/test/isolation/expected/eval-plan-qual.out b/src/test/isolation/expected/eval-plan-qual.out
index 3d31d0f84e5..485cf0eb912 100644
--- a/src/test/isolation/expected/eval-plan-qual.out
+++ b/src/test/isolation/expected/eval-plan-qual.out
@@ -1,4 +1,4 @@
-Parsed test spec with 3 sessions
+Parsed test spec with 5 sessions
starting permutation: wx1 wx2 c1 c2 read
step wx1: UPDATE accounts SET balance = balance - 200 WHERE accountid = 'checking' RETURNING balance;
@@ -1457,3 +1457,19 @@ step sysmerge2:
step c1: COMMIT;
step sysmerge2: <... completed>
step c2: COMMIT;
+
+starting permutation: s4pp1 s4pp2 s5pp1 s5pp2 s5pp3 s4pp3 s5pp4 s5pp5
+step s4pp1: BEGIN;
+step s4pp2: UPDATE another_parttbl SET b = b + 1 WHERE a = 1;
+step s5pp1: SET plan_cache_mode TO force_generic_plan;
+step s5pp2: PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1;
+step s5pp3: EXECUTE epd(1); <waiting ...>
+step s4pp3: COMMIT;
+step s5pp3: <... completed>
+step s5pp4: SELECT count(*) FROM another_parttbl;
+count
+-----
+ 0
+(1 row)
+
+step s5pp5: DEALLOCATE epd;
diff --git a/src/test/isolation/specs/eval-plan-qual.spec b/src/test/isolation/specs/eval-plan-qual.spec
index c6eee685586..b9bb4c75e8c 100644
--- a/src/test/isolation/specs/eval-plan-qual.spec
+++ b/src/test/isolation/specs/eval-plan-qual.spec
@@ -343,6 +343,21 @@ step multireadwcte {
teardown { COMMIT; }
+# Exercise run-time partition pruning code in an EPQ recheck
+session s4
+
+step s4pp1 { BEGIN; }
+step s4pp2 { UPDATE another_parttbl SET b = b + 1 WHERE a = 1; }
+step s4pp3 { COMMIT; }
+
+session s5
+
+step s5pp1 { SET plan_cache_mode TO force_generic_plan; }
+step s5pp2 { PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1; }
+step s5pp3 { EXECUTE epd(1); }
+step s5pp4 { SELECT count(*) FROM another_parttbl; }
+step s5pp5 { DEALLOCATE epd;}
+
# test that normal update follows update chains, and reverifies quals
permutation wx1 wx2 c1 c2 read
permutation wy1 wy2 c1 c2 read
@@ -415,3 +430,6 @@ permutation simplepartupdate_noroute complexpartupdate_doesnt_route c1 c2 read_p
permutation sys1 sysupd2 c1 c2
permutation sys1 sysmerge2 c1 c2
+
+# Exercise run-time partition pruning code in an EPQ recheck
+permutation s4pp1 s4pp2 s5pp1 s5pp2 s5pp3 s4pp3 s5pp4 s5pp5
--
2.43.0
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:56 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:09 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:15 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 06:20 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
@ 2025-09-18 07:05 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 08:25 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: David Rowley @ 2025-09-18 07:05 UTC (permalink / raw)
To: Amit Langote <amitlangote09@gmail.com>; +Cc: feichanghong <feichanghong@qq.com>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org
On Thu, 18 Sept 2025 at 18:20, Amit Langote <amitlangote09@gmail.com> wrote:
> Oops, coffee deficiency. Updated again.
Thanks for updating the patch.
I think the original intent of "Parsed test spec with 3 sessions"
(from 759d9d676) was two sessions doing work, and an independent
observer session. Is there a reason to add 2 more sessions? Maybe it's
me not working with the isolation tester often enough, but I'd have
expected you to add steps for s1 and s2 then define permutations for
those steps.
David
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:56 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:09 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:15 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 06:20 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 07:05 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
@ 2025-09-18 08:25 ` Amit Langote <amitlangote09@gmail.com>
2025-09-19 02:05 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Amit Langote @ 2025-09-18 08:25 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: feichanghong <feichanghong@qq.com>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org
On Thu, Sep 18, 2025 at 4:06 PM David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Thu, 18 Sept 2025 at 18:20, Amit Langote <amitlangote09@gmail.com> wrote:
> > Oops, coffee deficiency. Updated again.
>
> Thanks for updating the patch.
>
> I think the original intent of "Parsed test spec with 3 sessions"
> (from 759d9d676) was two sessions doing work, and an independent
> observer session. Is there a reason to add 2 more sessions? Maybe it's
> me not working with the isolation tester often enough, but I'd have
> expected you to add steps for s1 and s2 then define permutations for
> those steps.
Yeah, that makes the additions smaller and avoids slowing down the
suite. It did take a bit of fiddling though -- after switching to use
the existing sessions, teardown in s1 hung because I hadn’t noticed
that s2’s setup already does a BEGIN, so the delete side ended up
without a COMMIT, leaving an open transaction that blocked DROP in
s1’s teardown. Easier to take shortcuts with new sessions like I
first did, but better to keep the suite light. :-)
Done in the attached.
--
Thanks, Amit Langote
Attachments:
[application/octet-stream] v6-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch (4.1K, ../../CA+HiwqF2jPPZL1Kj-qo=pTnjKE_As-JvTvy8zMj0qEu+Gc=HaA@mail.gmail.com/2-v6-0001-Fix-EPQ-crash-from-missing-partition-pruning-stat.patch)
download | inline diff:
From 9db806f359da19375f9cfa4b2080aacdb9add1fe Mon Sep 17 00:00:00 2001
From: Amit Langote <amitlan@postgresql.org>
Date: Thu, 18 Sep 2025 15:00:21 +0900
Subject: [PATCH v6] Fix EPQ crash from missing partition pruning state in
EState
Commit bb3ec16e14 moved partition pruning metadata into PlannedStmt.
At executor startup this metadata is used to initialize the EState
fields es_part_prune_infos, es_part_prune_states, and
es_part_prune_results. EvalPlanQualStart() failed to copy those
fields into the child EState, causing NULL dereference when Append
ran partition pruning during a recheck. This can occur with DELETE
or UPDATE on partitioned tables that use runtime pruning, e.g. with
generic plans.
Fix by copying all partition pruning state into the EPQ estate.
Add an isolation test that reproduces the crash with concurrent
UPDATE and DELETE on a partitioned table, where the DELETE session
hits the crash during its EPQ recheck after the UPDATE commits.
Bug: #19056
Reported-by: Fei Changhong <feichanghong@qq.com>
Diagnozed-by: Fei Changhong <feichanghong@qq.com>
Author: David Rowley <dgrowleyml@gmail.com>
Co-authored-by: Amit Langote <amitlangote09@gmail.com>
Discussion: https://postgr.es/m/19056-a677cef9b54d76a0%40postgresql.org
---
src/backend/executor/execMain.c | 9 +++++++++
src/test/isolation/expected/eval-plan-qual.out | 9 +++++++++
src/test/isolation/specs/eval-plan-qual.spec | 8 ++++++++
3 files changed, 26 insertions(+)
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index ff12e2e1364..831c55ce787 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -3084,6 +3084,15 @@ EvalPlanQualStart(EPQState *epqstate, Plan *planTree)
*/
rcestate->es_unpruned_relids = parentestate->es_unpruned_relids;
+ /*
+ * Also make the PartitionPruneInfo and the results of pruning available.
+ * These need to match exactly so that we initialize all the same Append
+ * and MergeAppend subplans as the parent did.
+ */
+ rcestate->es_part_prune_infos = parentestate->es_part_prune_infos;
+ rcestate->es_part_prune_states = parentestate->es_part_prune_states;
+ rcestate->es_part_prune_results = parentestate->es_part_prune_results;
+
/*
* Initialize private state information for each SubPlan. We must do this
* before running ExecInitNode on the main query tree, since
diff --git a/src/test/isolation/expected/eval-plan-qual.out b/src/test/isolation/expected/eval-plan-qual.out
index 3d31d0f84e5..60eca44b4e3 100644
--- a/src/test/isolation/expected/eval-plan-qual.out
+++ b/src/test/isolation/expected/eval-plan-qual.out
@@ -1457,3 +1457,12 @@ step sysmerge2:
step c1: COMMIT;
step sysmerge2: <... completed>
step c2: COMMIT;
+
+starting permutation: s1pp1 s2pp1 s2pp2 s2pp3 c1 c2
+step s1pp1: UPDATE another_parttbl SET b = b + 1 WHERE a = 1;
+step s2pp1: SET plan_cache_mode TO force_generic_plan;
+step s2pp2: PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1;
+step s2pp3: EXECUTE epd(1); <waiting ...>
+step c1: COMMIT;
+step s2pp3: <... completed>
+step c2: COMMIT;
diff --git a/src/test/isolation/specs/eval-plan-qual.spec b/src/test/isolation/specs/eval-plan-qual.spec
index c6eee685586..64afffb1d83 100644
--- a/src/test/isolation/specs/eval-plan-qual.spec
+++ b/src/test/isolation/specs/eval-plan-qual.spec
@@ -204,6 +204,7 @@ step sys1 {
UPDATE pg_class SET reltuples = 123 WHERE oid = 'accounts'::regclass;
}
+step s1pp1 { UPDATE another_parttbl SET b = b + 1 WHERE a = 1; }
session s2
setup { BEGIN ISOLATION LEVEL READ COMMITTED; }
@@ -312,6 +313,10 @@ step sysmerge2 {
step c2 { COMMIT; }
step r2 { ROLLBACK; }
+step s2pp1 { SET plan_cache_mode TO force_generic_plan; }
+step s2pp2 { PREPARE epd AS DELETE FROM another_parttbl WHERE a = $1; }
+step s2pp3 { EXECUTE epd(1); }
+
session s3
setup { BEGIN ISOLATION LEVEL READ COMMITTED; }
step read { SELECT * FROM accounts ORDER BY accountid; }
@@ -415,3 +420,6 @@ permutation simplepartupdate_noroute complexpartupdate_doesnt_route c1 c2 read_p
permutation sys1 sysupd2 c1 c2
permutation sys1 sysmerge2 c1 c2
+
+# Exercise run-time partition pruning code in an EPQ recheck
+permutation s1pp1 s2pp1 s2pp2 s2pp3 c1 c2
--
2.43.0
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:56 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:09 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:15 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 06:20 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 07:05 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 08:25 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
@ 2025-09-19 02:05 ` David Rowley <dgrowleyml@gmail.com>
2025-09-19 02:42 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: David Rowley @ 2025-09-19 02:05 UTC (permalink / raw)
To: Amit Langote <amitlangote09@gmail.com>; +Cc: feichanghong <feichanghong@qq.com>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org
On Thu, 18 Sept 2025 at 20:25, Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Sep 18, 2025 at 4:06 PM David Rowley <dgrowleyml@gmail.com> wrote:
> > I think the original intent of "Parsed test spec with 3 sessions"
> > (from 759d9d676) was two sessions doing work, and an independent
> > observer session. Is there a reason to add 2 more sessions? Maybe it's
> > me not working with the isolation tester often enough, but I'd have
> > expected you to add steps for s1 and s2 then define permutations for
> > those steps.
>
> Yeah, that makes the additions smaller and avoids slowing down the
> suite. It did take a bit of fiddling though -- after switching to use
> the existing sessions, teardown in s1 hung because I hadn’t noticed
> that s2’s setup already does a BEGIN, so the delete side ended up
> without a COMMIT, leaving an open transaction that blocked DROP in
> s1’s teardown. Easier to take shortcuts with new sessions like I
> first did, but better to keep the suite light. :-)
>
> Done in the attached.
Thanks for updating. Looks good. I verified the test fails with the
code change reverted and passes with the change.
David
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:56 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:09 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:15 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos feichanghong <feichanghong@qq.com>
2025-09-18 06:20 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-18 07:05 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
2025-09-18 08:25 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos Amit Langote <amitlangote09@gmail.com>
2025-09-19 02:05 ` Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos David Rowley <dgrowleyml@gmail.com>
@ 2025-09-19 02:42 ` Amit Langote <amitlangote09@gmail.com>
0 siblings, 0 replies; 21+ messages in thread
From: Amit Langote @ 2025-09-19 02:42 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: feichanghong <feichanghong@qq.com>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org
On Fri, Sep 19, 2025 at 11:05 AM David Rowley <dgrowleyml@gmail.com> wrote:
> On Thu, 18 Sept 2025 at 20:25, Amit Langote <amitlangote09@gmail.com> wrote:
> >
> > On Thu, Sep 18, 2025 at 4:06 PM David Rowley <dgrowleyml@gmail.com> wrote:
> > > I think the original intent of "Parsed test spec with 3 sessions"
> > > (from 759d9d676) was two sessions doing work, and an independent
> > > observer session. Is there a reason to add 2 more sessions? Maybe it's
> > > me not working with the isolation tester often enough, but I'd have
> > > expected you to add steps for s1 and s2 then define permutations for
> > > those steps.
> >
> > Yeah, that makes the additions smaller and avoids slowing down the
> > suite. It did take a bit of fiddling though -- after switching to use
> > the existing sessions, teardown in s1 hung because I hadn’t noticed
> > that s2’s setup already does a BEGIN, so the delete side ended up
> > without a COMMIT, leaving an open transaction that blocked DROP in
> > s1’s teardown. Easier to take shortcuts with new sessions like I
> > first did, but better to keep the suite light. :-)
> >
> > Done in the attached.
>
> Thanks for updating. Looks good. I verified the test fails with the
> code change reverted and passes with the change.
Thanks for checking, pushed.
--
Thanks, Amit Langote
^ permalink raw reply [nested|flat] 21+ messages in thread
end of thread, other threads:[~2025-09-19 02:42 UTC | newest]
Thread overview: 21+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-09-17 15:08 BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos PG Bug reporting form <noreply@postgresql.org>
2025-09-17 21:43 ` David Rowley <dgrowleyml@gmail.com>
2025-09-17 22:32 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 01:33 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 01:58 ` feichanghong <feichanghong@qq.com>
2025-09-18 03:10 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:37 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 03:47 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 04:19 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:29 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-09-18 05:15 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 04:56 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:09 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 06:15 ` feichanghong <feichanghong@qq.com>
2025-09-18 06:20 ` Amit Langote <amitlangote09@gmail.com>
2025-09-18 07:05 ` David Rowley <dgrowleyml@gmail.com>
2025-09-18 08:25 ` Amit Langote <amitlangote09@gmail.com>
2025-09-19 02:05 ` David Rowley <dgrowleyml@gmail.com>
2025-09-19 02:42 ` Amit Langote <amitlangote09@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox