pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix Assert failure in WITH RECURSIVE UNION queries 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix Assert failure in WITH RECURSIVE UNION queries @ 2024-12-19 00:12 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2024-12-19 00:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix Assert failure in WITH RECURSIVE UNION queries If the non-recursive part of a recursive CTE ended up using TTSOpsBufferHeapTuple as the table slot type, then a duplicate value could cause an Assert failure in CheckOpSlotCompatibility() when checking the hash table for the duplicate value. The expected slot type for the deform step was TTSOpsMinimalTuple so the Assert failed when the TTSOpsBufferHeapTuple slot was used. This is a long-standing bug which we likely didn't notice because it seems much more likely that the non-recursive term would have required projection and used a TTSOpsVirtual slot, which CheckOpSlotCompatibility is ok with. There doesn't seem to be any harm done here other than the Assert failure. Both TTSOpsMinimalTuple and TTSOpsBufferHeapTuple slot types require tuple deformation, so the EEOP_*_FETCHSOME ExprState step would have properly existed in the ExprState. The solution is to pass NULL for the ExecBuildGroupingEqual's 'lops' parameter. This means the ExprState's EEOP_*_FETCHSOME step won't expect a fixed slot type. This makes CheckOpSlotCompatibility() happy as no checking is performed when the ExprEvalStep is not expecting a fixed slot type. Reported-by: Richard Guo Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAMbWs4-8U9q2LAtf8+ghV11zeUReA3AmrYkxzBEv0vKnDxwkKA@mail.gmail.com Backpatch-through: 13, all supported versions Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/8f4ee962691ed36302be3333c65422ed9e082743 Modified Files -------------- src/backend/executor/execGrouping.c | 3 +-- src/test/regress/expected/with.out | 15 +++++++++++++++ src/test/regress/sql/with.sql | 12 ++++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix Assert failure in WITH RECURSIVE UNION queries @ 2024-12-19 00:12 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2024-12-19 00:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix Assert failure in WITH RECURSIVE UNION queries If the non-recursive part of a recursive CTE ended up using TTSOpsBufferHeapTuple as the table slot type, then a duplicate value could cause an Assert failure in CheckOpSlotCompatibility() when checking the hash table for the duplicate value. The expected slot type for the deform step was TTSOpsMinimalTuple so the Assert failed when the TTSOpsBufferHeapTuple slot was used. This is a long-standing bug which we likely didn't notice because it seems much more likely that the non-recursive term would have required projection and used a TTSOpsVirtual slot, which CheckOpSlotCompatibility is ok with. There doesn't seem to be any harm done here other than the Assert failure. Both TTSOpsMinimalTuple and TTSOpsBufferHeapTuple slot types require tuple deformation, so the EEOP_*_FETCHSOME ExprState step would have properly existed in the ExprState. The solution is to pass NULL for the ExecBuildGroupingEqual's 'lops' parameter. This means the ExprState's EEOP_*_FETCHSOME step won't expect a fixed slot type. This makes CheckOpSlotCompatibility() happy as no checking is performed when the ExprEvalStep is not expecting a fixed slot type. Reported-by: Richard Guo Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAMbWs4-8U9q2LAtf8+ghV11zeUReA3AmrYkxzBEv0vKnDxwkKA@mail.gmail.com Backpatch-through: 13, all supported versions Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7b8d45d278de62b23777b36e1515c34d2eaeaf66 Modified Files -------------- src/backend/executor/execGrouping.c | 3 +-- src/test/regress/expected/with.out | 15 +++++++++++++++ src/test/regress/sql/with.sql | 12 ++++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix Assert failure in WITH RECURSIVE UNION queries @ 2024-12-19 00:12 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2024-12-19 00:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix Assert failure in WITH RECURSIVE UNION queries If the non-recursive part of a recursive CTE ended up using TTSOpsBufferHeapTuple as the table slot type, then a duplicate value could cause an Assert failure in CheckOpSlotCompatibility() when checking the hash table for the duplicate value. The expected slot type for the deform step was TTSOpsMinimalTuple so the Assert failed when the TTSOpsBufferHeapTuple slot was used. This is a long-standing bug which we likely didn't notice because it seems much more likely that the non-recursive term would have required projection and used a TTSOpsVirtual slot, which CheckOpSlotCompatibility is ok with. There doesn't seem to be any harm done here other than the Assert failure. Both TTSOpsMinimalTuple and TTSOpsBufferHeapTuple slot types require tuple deformation, so the EEOP_*_FETCHSOME ExprState step would have properly existed in the ExprState. The solution is to pass NULL for the ExecBuildGroupingEqual's 'lops' parameter. This means the ExprState's EEOP_*_FETCHSOME step won't expect a fixed slot type. This makes CheckOpSlotCompatibility() happy as no checking is performed when the ExprEvalStep is not expecting a fixed slot type. Reported-by: Richard Guo Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAMbWs4-8U9q2LAtf8+ghV11zeUReA3AmrYkxzBEv0vKnDxwkKA@mail.gmail.com Backpatch-through: 13, all supported versions Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/093fc156b0ef69fdbe2a345c4ba6bca461c62631 Modified Files -------------- src/backend/executor/execGrouping.c | 3 +-- src/test/regress/expected/with.out | 15 +++++++++++++++ src/test/regress/sql/with.sql | 12 ++++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix Assert failure in WITH RECURSIVE UNION queries @ 2024-12-19 00:13 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2024-12-19 00:13 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix Assert failure in WITH RECURSIVE UNION queries If the non-recursive part of a recursive CTE ended up using TTSOpsBufferHeapTuple as the table slot type, then a duplicate value could cause an Assert failure in CheckOpSlotCompatibility() when checking the hash table for the duplicate value. The expected slot type for the deform step was TTSOpsMinimalTuple so the Assert failed when the TTSOpsBufferHeapTuple slot was used. This is a long-standing bug which we likely didn't notice because it seems much more likely that the non-recursive term would have required projection and used a TTSOpsVirtual slot, which CheckOpSlotCompatibility is ok with. There doesn't seem to be any harm done here other than the Assert failure. Both TTSOpsMinimalTuple and TTSOpsBufferHeapTuple slot types require tuple deformation, so the EEOP_*_FETCHSOME ExprState step would have properly existed in the ExprState. The solution is to pass NULL for the ExecBuildGroupingEqual's 'lops' parameter. This means the ExprState's EEOP_*_FETCHSOME step won't expect a fixed slot type. This makes CheckOpSlotCompatibility() happy as no checking is performed when the ExprEvalStep is not expecting a fixed slot type. Reported-by: Richard Guo Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAMbWs4-8U9q2LAtf8+ghV11zeUReA3AmrYkxzBEv0vKnDxwkKA@mail.gmail.com Backpatch-through: 13, all supported versions Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ef178d38bb493baa49dc0824656e60717e8a8b1d Modified Files -------------- src/backend/executor/execGrouping.c | 3 +-- src/test/regress/expected/with.out | 15 +++++++++++++++ src/test/regress/sql/with.sql | 12 ++++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix Assert failure in WITH RECURSIVE UNION queries @ 2024-12-19 00:13 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2024-12-19 00:13 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix Assert failure in WITH RECURSIVE UNION queries If the non-recursive part of a recursive CTE ended up using TTSOpsBufferHeapTuple as the table slot type, then a duplicate value could cause an Assert failure in CheckOpSlotCompatibility() when checking the hash table for the duplicate value. The expected slot type for the deform step was TTSOpsMinimalTuple so the Assert failed when the TTSOpsBufferHeapTuple slot was used. This is a long-standing bug which we likely didn't notice because it seems much more likely that the non-recursive term would have required projection and used a TTSOpsVirtual slot, which CheckOpSlotCompatibility is ok with. There doesn't seem to be any harm done here other than the Assert failure. Both TTSOpsMinimalTuple and TTSOpsBufferHeapTuple slot types require tuple deformation, so the EEOP_*_FETCHSOME ExprState step would have properly existed in the ExprState. The solution is to pass NULL for the ExecBuildGroupingEqual's 'lops' parameter. This means the ExprState's EEOP_*_FETCHSOME step won't expect a fixed slot type. This makes CheckOpSlotCompatibility() happy as no checking is performed when the ExprEvalStep is not expecting a fixed slot type. Reported-by: Richard Guo Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAMbWs4-8U9q2LAtf8+ghV11zeUReA3AmrYkxzBEv0vKnDxwkKA@mail.gmail.com Backpatch-through: 13, all supported versions Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bdb07d24113b721f3c123304c162485f54e2f554 Modified Files -------------- src/backend/executor/execGrouping.c | 3 +-- src/test/regress/expected/with.out | 15 +++++++++++++++ src/test/regress/sql/with.sql | 12 ++++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix Assert failure in WITH RECURSIVE UNION queries @ 2024-12-19 00:14 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: David Rowley @ 2024-12-19 00:14 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix Assert failure in WITH RECURSIVE UNION queries If the non-recursive part of a recursive CTE ended up using TTSOpsBufferHeapTuple as the table slot type, then a duplicate value could cause an Assert failure in CheckOpSlotCompatibility() when checking the hash table for the duplicate value. The expected slot type for the deform step was TTSOpsMinimalTuple so the Assert failed when the TTSOpsBufferHeapTuple slot was used. This is a long-standing bug which we likely didn't notice because it seems much more likely that the non-recursive term would have required projection and used a TTSOpsVirtual slot, which CheckOpSlotCompatibility is ok with. There doesn't seem to be any harm done here other than the Assert failure. Both TTSOpsMinimalTuple and TTSOpsBufferHeapTuple slot types require tuple deformation, so the EEOP_*_FETCHSOME ExprState step would have properly existed in the ExprState. The solution is to pass NULL for the ExecBuildGroupingEqual's 'lops' parameter. This means the ExprState's EEOP_*_FETCHSOME step won't expect a fixed slot type. This makes CheckOpSlotCompatibility() happy as no checking is performed when the ExprEvalStep is not expecting a fixed slot type. Reported-by: Richard Guo Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAMbWs4-8U9q2LAtf8+ghV11zeUReA3AmrYkxzBEv0vKnDxwkKA@mail.gmail.com Backpatch-through: 13, all supported versions Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/2c7887c9d612abddf630d03f9abddf54eaa12a93 Modified Files -------------- src/backend/executor/execGrouping.c | 3 +-- src/test/regress/expected/with.out | 15 +++++++++++++++ src/test/regress/sql/with.sql | 12 ++++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-12-19 00:14 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-12-19 00:12 pgsql: Fix Assert failure in WITH RECURSIVE UNION queries David Rowley <drowley@postgresql.org> 2024-12-19 00:12 pgsql: Fix Assert failure in WITH RECURSIVE UNION queries David Rowley <drowley@postgresql.org> 2024-12-19 00:12 pgsql: Fix Assert failure in WITH RECURSIVE UNION queries David Rowley <drowley@postgresql.org> 2024-12-19 00:13 pgsql: Fix Assert failure in WITH RECURSIVE UNION queries David Rowley <drowley@postgresql.org> 2024-12-19 00:13 pgsql: Fix Assert failure in WITH RECURSIVE UNION queries David Rowley <drowley@postgresql.org> 2024-12-19 00:14 pgsql: Fix Assert failure in WITH RECURSIVE UNION queries 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