pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
pgsql: Fix incorrect logic for caching ResultRelInfos for triggers
5+ messages / 1 participants
[nested] [flat]

* pgsql: Fix incorrect logic for caching ResultRelInfos for triggers
@ 2025-10-25 22:01  David Rowley <drowley@postgresql.org>
  0 siblings, 0 replies; 5+ messages in thread

From: David Rowley @ 2025-10-25 22:01 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix incorrect logic for caching ResultRelInfos for triggers

When dealing with ResultRelInfos for partitions, there are cases where
there are mixed requirements for the ri_RootResultRelInfo.  There are
cases when the partition itself requires a NULL ri_RootResultRelInfo and
in the same query, the same partition may require a ResultRelInfo with
its parent set in ri_RootResultRelInfo.  This could cause the column
mapping between the partitioned table and the partition not to be done
which could result in crashes if the column attnums didn't match
exactly.

The fix is simple.  We now check that the ri_RootResultRelInfo matches
what the caller passed to ExecGetTriggerResultRel() and only return a
cached ResultRelInfo when the ri_RootResultRelInfo matches what the
caller wants, otherwise we'll make a new one.

Author: David Rowley <dgrowleyml@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reported-by: Dmitry Fomin <fomin.list@gmail.com>
Discussion: https://postgr.es/m/7DCE78D7-0520-4207-822B-92F60AEA14B4@gmail.com
Backpatch-through: 15

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/39dcfda2d23ac39f14ecf4b83e01eae85d07d9e5

Modified Files
--------------
src/backend/executor/execMain.c           | 24 ++++++++++-----
src/test/regress/expected/foreign_key.out | 51 +++++++++++++++++++++++++++++++
src/test/regress/sql/foreign_key.sql      | 48 +++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 7 deletions(-)



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* pgsql: Fix incorrect logic for caching ResultRelInfos for triggers
@ 2025-10-25 22:01  David Rowley <drowley@postgresql.org>
  0 siblings, 0 replies; 5+ messages in thread

From: David Rowley @ 2025-10-25 22:01 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix incorrect logic for caching ResultRelInfos for triggers

When dealing with ResultRelInfos for partitions, there are cases where
there are mixed requirements for the ri_RootResultRelInfo.  There are
cases when the partition itself requires a NULL ri_RootResultRelInfo and
in the same query, the same partition may require a ResultRelInfo with
its parent set in ri_RootResultRelInfo.  This could cause the column
mapping between the partitioned table and the partition not to be done
which could result in crashes if the column attnums didn't match
exactly.

The fix is simple.  We now check that the ri_RootResultRelInfo matches
what the caller passed to ExecGetTriggerResultRel() and only return a
cached ResultRelInfo when the ri_RootResultRelInfo matches what the
caller wants, otherwise we'll make a new one.

Author: David Rowley <dgrowleyml@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reported-by: Dmitry Fomin <fomin.list@gmail.com>
Discussion: https://postgr.es/m/7DCE78D7-0520-4207-822B-92F60AEA14B4@gmail.com
Backpatch-through: 15

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/a2387c32f2f8a1643c7d71b951587e6bcb2d4744

Modified Files
--------------
src/backend/executor/execMain.c           | 24 ++++++++++-----
src/test/regress/expected/foreign_key.out | 51 +++++++++++++++++++++++++++++++
src/test/regress/sql/foreign_key.sql      | 48 +++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 7 deletions(-)



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* pgsql: Fix incorrect logic for caching ResultRelInfos for triggers
@ 2025-10-25 22:02  David Rowley <drowley@postgresql.org>
  0 siblings, 0 replies; 5+ messages in thread

From: David Rowley @ 2025-10-25 22:02 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix incorrect logic for caching ResultRelInfos for triggers

When dealing with ResultRelInfos for partitions, there are cases where
there are mixed requirements for the ri_RootResultRelInfo.  There are
cases when the partition itself requires a NULL ri_RootResultRelInfo and
in the same query, the same partition may require a ResultRelInfo with
its parent set in ri_RootResultRelInfo.  This could cause the column
mapping between the partitioned table and the partition not to be done
which could result in crashes if the column attnums didn't match
exactly.

The fix is simple.  We now check that the ri_RootResultRelInfo matches
what the caller passed to ExecGetTriggerResultRel() and only return a
cached ResultRelInfo when the ri_RootResultRelInfo matches what the
caller wants, otherwise we'll make a new one.

Author: David Rowley <dgrowleyml@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reported-by: Dmitry Fomin <fomin.list@gmail.com>
Discussion: https://postgr.es/m/7DCE78D7-0520-4207-822B-92F60AEA14B4@gmail.com
Backpatch-through: 15

Branch
------
REL_17_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/0d307461538082880151c804e037ab3bd85936e7

Modified Files
--------------
src/backend/executor/execMain.c           | 24 ++++++++++-----
src/test/regress/expected/foreign_key.out | 51 +++++++++++++++++++++++++++++++
src/test/regress/sql/foreign_key.sql      | 48 +++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 7 deletions(-)



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* pgsql: Fix incorrect logic for caching ResultRelInfos for triggers
@ 2025-10-25 22:02  David Rowley <drowley@postgresql.org>
  0 siblings, 0 replies; 5+ messages in thread

From: David Rowley @ 2025-10-25 22:02 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix incorrect logic for caching ResultRelInfos for triggers

When dealing with ResultRelInfos for partitions, there are cases where
there are mixed requirements for the ri_RootResultRelInfo.  There are
cases when the partition itself requires a NULL ri_RootResultRelInfo and
in the same query, the same partition may require a ResultRelInfo with
its parent set in ri_RootResultRelInfo.  This could cause the column
mapping between the partitioned table and the partition not to be done
which could result in crashes if the column attnums didn't match
exactly.

The fix is simple.  We now check that the ri_RootResultRelInfo matches
what the caller passed to ExecGetTriggerResultRel() and only return a
cached ResultRelInfo when the ri_RootResultRelInfo matches what the
caller wants, otherwise we'll make a new one.

Author: David Rowley <dgrowleyml@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reported-by: Dmitry Fomin <fomin.list@gmail.com>
Discussion: https://postgr.es/m/7DCE78D7-0520-4207-822B-92F60AEA14B4@gmail.com
Backpatch-through: 15

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/a546964db6fbb2e3afdb08940fdd322b957e9447

Modified Files
--------------
src/backend/executor/execMain.c           | 24 ++++++++++-----
src/test/regress/expected/foreign_key.out | 51 +++++++++++++++++++++++++++++++
src/test/regress/sql/foreign_key.sql      | 48 +++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 7 deletions(-)



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* pgsql: Fix incorrect logic for caching ResultRelInfos for triggers
@ 2025-10-25 22:02  David Rowley <drowley@postgresql.org>
  0 siblings, 0 replies; 5+ messages in thread

From: David Rowley @ 2025-10-25 22:02 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix incorrect logic for caching ResultRelInfos for triggers

When dealing with ResultRelInfos for partitions, there are cases where
there are mixed requirements for the ri_RootResultRelInfo.  There are
cases when the partition itself requires a NULL ri_RootResultRelInfo and
in the same query, the same partition may require a ResultRelInfo with
its parent set in ri_RootResultRelInfo.  This could cause the column
mapping between the partitioned table and the partition not to be done
which could result in crashes if the column attnums didn't match
exactly.

The fix is simple.  We now check that the ri_RootResultRelInfo matches
what the caller passed to ExecGetTriggerResultRel() and only return a
cached ResultRelInfo when the ri_RootResultRelInfo matches what the
caller wants, otherwise we'll make a new one.

Author: David Rowley <dgrowleyml@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Reported-by: Dmitry Fomin <fomin.list@gmail.com>
Discussion: https://postgr.es/m/7DCE78D7-0520-4207-822B-92F60AEA14B4@gmail.com
Backpatch-through: 15

Branch
------
REL_15_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/2992b9a07ef028792552fff20818a83c579a0b73

Modified Files
--------------
src/backend/executor/execMain.c           | 24 ++++++++++-----
src/test/regress/expected/foreign_key.out | 51 +++++++++++++++++++++++++++++++
src/test/regress/sql/foreign_key.sql      | 48 +++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 7 deletions(-)



^ permalink  raw  reply  [nested|flat] 5+ messages in thread


end of thread, other threads:[~2025-10-25 22:02 UTC | newest]

Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-10-25 22:01 pgsql: Fix incorrect logic for caching ResultRelInfos for triggers David Rowley <drowley@postgresql.org>
2025-10-25 22:01 pgsql: Fix incorrect logic for caching ResultRelInfos for triggers David Rowley <drowley@postgresql.org>
2025-10-25 22:02 pgsql: Fix incorrect logic for caching ResultRelInfos for triggers David Rowley <drowley@postgresql.org>
2025-10-25 22:02 pgsql: Fix incorrect logic for caching ResultRelInfos for triggers David Rowley <drowley@postgresql.org>
2025-10-25 22:02 pgsql: Fix incorrect logic for caching ResultRelInfos for triggers David Rowley <drowley@postgresql.org>

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