pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code @ 2025-10-23 00:11 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2025-10-23 00:11 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix incorrect zero extension of Datum in JIT tuple deform code When JIT deformed tuples (controlled via the jit_tuple_deforming GUC), types narrower than sizeof(Datum) would be zero-extended up to Datum width. This wasn't the same as what fetch_att() does in the standard tuple deforming code. Logically the values are the same when fetching via the DatumGet*() marcos, but negative numbers are not the same in binary form. In the report, the problem was manifesting itself with: ERROR: could not find memoization table entry in a query which had a "Cache Mode: binary" Memoize node. However, it's currently unclear what else is affected. Anything that uses datum_image_eq() or datum_image_hash() on a Datum from a tuple deformed by JIT could be affected, but it may not be limited to that. The fix for this is simple: use signed extension instead of zero extension. Many thanks to Emmanuel Touzery for reporting this issue and providing steps and backup which allowed the problem to easily be recreated. Reported-by: Emmanuel Touzery <emmanuel.touzery@plandela.si> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/DB8P194MB08532256D5BAF894F241C06393F3A@DB8P194MB0853.EURP194.PROD.OUTLOOK.COM Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/6911f80379d48744c70e7ea7731b783c8fec01d2 Modified Files -------------- src/backend/jit/llvm/llvmjit_deform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code @ 2025-10-23 00:12 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2025-10-23 00:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix incorrect zero extension of Datum in JIT tuple deform code When JIT deformed tuples (controlled via the jit_tuple_deforming GUC), types narrower than sizeof(Datum) would be zero-extended up to Datum width. This wasn't the same as what fetch_att() does in the standard tuple deforming code. Logically the values are the same when fetching via the DatumGet*() marcos, but negative numbers are not the same in binary form. In the report, the problem was manifesting itself with: ERROR: could not find memoization table entry in a query which had a "Cache Mode: binary" Memoize node. However, it's currently unclear what else is affected. Anything that uses datum_image_eq() or datum_image_hash() on a Datum from a tuple deformed by JIT could be affected, but it may not be limited to that. The fix for this is simple: use signed extension instead of zero extension. Many thanks to Emmanuel Touzery for reporting this issue and providing steps and backup which allowed the problem to easily be recreated. Reported-by: Emmanuel Touzery <emmanuel.touzery@plandela.si> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/DB8P194MB08532256D5BAF894F241C06393F3A@DB8P194MB0853.EURP194.PROD.OUTLOOK.COM Backpatch-through: 13 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ceb51d09b46b5f75a8fa94c169e570b02a370461 Modified Files -------------- src/backend/jit/llvm/llvmjit_deform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code @ 2025-10-23 00:13 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2025-10-23 00:13 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix incorrect zero extension of Datum in JIT tuple deform code When JIT deformed tuples (controlled via the jit_tuple_deforming GUC), types narrower than sizeof(Datum) would be zero-extended up to Datum width. This wasn't the same as what fetch_att() does in the standard tuple deforming code. Logically the values are the same when fetching via the DatumGet*() marcos, but negative numbers are not the same in binary form. In the report, the problem was manifesting itself with: ERROR: could not find memoization table entry in a query which had a "Cache Mode: binary" Memoize node. However, it's currently unclear what else is affected. Anything that uses datum_image_eq() or datum_image_hash() on a Datum from a tuple deformed by JIT could be affected, but it may not be limited to that. The fix for this is simple: use signed extension instead of zero extension. Many thanks to Emmanuel Touzery for reporting this issue and providing steps and backup which allowed the problem to easily be recreated. Reported-by: Emmanuel Touzery <emmanuel.touzery@plandela.si> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/DB8P194MB08532256D5BAF894F241C06393F3A@DB8P194MB0853.EURP194.PROD.OUTLOOK.COM Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/10945148eec689cc114fe872d623c3c7c4f546e6 Modified Files -------------- src/backend/jit/llvm/llvmjit_deform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code @ 2025-10-23 00:13 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2025-10-23 00:13 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix incorrect zero extension of Datum in JIT tuple deform code When JIT deformed tuples (controlled via the jit_tuple_deforming GUC), types narrower than sizeof(Datum) would be zero-extended up to Datum width. This wasn't the same as what fetch_att() does in the standard tuple deforming code. Logically the values are the same when fetching via the DatumGet*() marcos, but negative numbers are not the same in binary form. In the report, the problem was manifesting itself with: ERROR: could not find memoization table entry in a query which had a "Cache Mode: binary" Memoize node. However, it's currently unclear what else is affected. Anything that uses datum_image_eq() or datum_image_hash() on a Datum from a tuple deformed by JIT could be affected, but it may not be limited to that. The fix for this is simple: use signed extension instead of zero extension. Many thanks to Emmanuel Touzery for reporting this issue and providing steps and backup which allowed the problem to easily be recreated. Reported-by: Emmanuel Touzery <emmanuel.touzery@plandela.si> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/DB8P194MB08532256D5BAF894F241C06393F3A@DB8P194MB0853.EURP194.PROD.OUTLOOK.COM Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3398b0d027852ff1ef4a3be28612a5731f6e52f3 Modified Files -------------- src/backend/jit/llvm/llvmjit_deform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code @ 2025-10-23 00:14 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2025-10-23 00:14 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix incorrect zero extension of Datum in JIT tuple deform code When JIT deformed tuples (controlled via the jit_tuple_deforming GUC), types narrower than sizeof(Datum) would be zero-extended up to Datum width. This wasn't the same as what fetch_att() does in the standard tuple deforming code. Logically the values are the same when fetching via the DatumGet*() marcos, but negative numbers are not the same in binary form. In the report, the problem was manifesting itself with: ERROR: could not find memoization table entry in a query which had a "Cache Mode: binary" Memoize node. However, it's currently unclear what else is affected. Anything that uses datum_image_eq() or datum_image_hash() on a Datum from a tuple deformed by JIT could be affected, but it may not be limited to that. The fix for this is simple: use signed extension instead of zero extension. Many thanks to Emmanuel Touzery for reporting this issue and providing steps and backup which allowed the problem to easily be recreated. Reported-by: Emmanuel Touzery <emmanuel.touzery@plandela.si> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/DB8P194MB08532256D5BAF894F241C06393F3A@DB8P194MB0853.EURP194.PROD.OUTLOOK.COM Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b8ecfbe5af4f1ccb7be582fe43b6568a7e8dd02b Modified Files -------------- src/backend/jit/llvm/llvmjit_deform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code @ 2025-10-23 00:14 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2025-10-23 00:14 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix incorrect zero extension of Datum in JIT tuple deform code When JIT deformed tuples (controlled via the jit_tuple_deforming GUC), types narrower than sizeof(Datum) would be zero-extended up to Datum width. This wasn't the same as what fetch_att() does in the standard tuple deforming code. Logically the values are the same when fetching via the DatumGet*() marcos, but negative numbers are not the same in binary form. In the report, the problem was manifesting itself with: ERROR: could not find memoization table entry in a query which had a "Cache Mode: binary" Memoize node. However, it's currently unclear what else is affected. Anything that uses datum_image_eq() or datum_image_hash() on a Datum from a tuple deformed by JIT could be affected, but it may not be limited to that. The fix for this is simple: use signed extension instead of zero extension. Many thanks to Emmanuel Touzery for reporting this issue and providing steps and backup which allowed the problem to easily be recreated. Reported-by: Emmanuel Touzery <emmanuel.touzery@plandela.si> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/DB8P194MB08532256D5BAF894F241C06393F3A@DB8P194MB0853.EURP194.PROD.OUTLOOK.COM Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e4316ec4dd0cc9ef777185a59556249656f5a0ed Modified Files -------------- src/backend/jit/llvm/llvmjit_deform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code @ 2025-10-23 00:14 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2025-10-23 00:14 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix incorrect zero extension of Datum in JIT tuple deform code When JIT deformed tuples (controlled via the jit_tuple_deforming GUC), types narrower than sizeof(Datum) would be zero-extended up to Datum width. This wasn't the same as what fetch_att() does in the standard tuple deforming code. Logically the values are the same when fetching via the DatumGet*() marcos, but negative numbers are not the same in binary form. In the report, the problem was manifesting itself with: ERROR: could not find memoization table entry in a query which had a "Cache Mode: binary" Memoize node. However, it's currently unclear what else is affected. Anything that uses datum_image_eq() or datum_image_hash() on a Datum from a tuple deformed by JIT could be affected, but it may not be limited to that. The fix for this is simple: use signed extension instead of zero extension. Many thanks to Emmanuel Touzery for reporting this issue and providing steps and backup which allowed the problem to easily be recreated. Reported-by: Emmanuel Touzery <emmanuel.touzery@plandela.si> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/DB8P194MB08532256D5BAF894F241C06393F3A@DB8P194MB0853.EURP194.PROD.OUTLOOK.COM Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4afab175bc13a08277ad40400a11db4e16905547 Modified Files -------------- src/backend/jit/llvm/llvmjit_deform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2025-10-23 00:14 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-10-23 00:11 pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code David Rowley <drowley@postgresql.org> 2025-10-23 00:12 pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code David Rowley <drowley@postgresql.org> 2025-10-23 00:13 pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code David Rowley <drowley@postgresql.org> 2025-10-23 00:13 pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code David Rowley <drowley@postgresql.org> 2025-10-23 00:14 pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code David Rowley <drowley@postgresql.org> 2025-10-23 00:14 pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code David Rowley <drowley@postgresql.org> 2025-10-23 00:14 pgsql: Fix incorrect zero extension of Datum in JIT tuple deform code 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