| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fix tuple deformation with virtual generated NOT NULL columns |
| Date: | 2026-06-17 22:45:49 |
| Message-ID: | 1174236.1781736349@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Speculating wildly, I'm wondering about an uninitialized variable that
> happens to usually have the right value.
Nope: valgrind finds nothing, and neither does debug_discard_caches.
What does reproduce it, with seeming 100% reliability, is
set jit = 1;
set jit_above_cost = 0;
set jit_optimize_above_cost = 1000;
CREATE TABLE gtest21c (a int NOT NULL, b int GENERATED ALWAYS AS (a * 2) VIRTUAL NOT NULL, c int NOT NULL);
INSERT INTO gtest21c (a, c) VALUES (10, 42);
table gtest21c;
I conclude that something in the JIT code for tuple formation
is unaware of virtual generated columns.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2026-06-17 22:46:27 | Re: DOCS - Clarify behaviour when EXCEPT tables are moved/renamed |
| Previous Message | Tom Lane | 2026-06-17 22:23:00 | Re: Fix tuple deformation with virtual generated NOT NULL columns |