David Rowley <dgrowleyml@gmail.com> writes:
> I pushed the patch to add the new test after modifying it to also
> include the change in the generated_stored test, but with it commented
> out. This is the method that 83ea6c540 introduced.
The buildfarm is showing clear evidence of a bug here somewhere:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bushmaster&dt=2026-06-17%2021%3A53%3A38
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=taipan&dt=2026-06-17%2018%3A50%3A42
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=canebrake&dt=2026-06-17%2018%3A02%3A59
All three failures look like
diff -U3 /home/bf/bf-build/taipan/HEAD/pgsql/src/test/regress/expected/generated_virtual.out
/home/bf/bf-build/taipan/HEAD/pgsql.build/src/test/regress/results/generated_virtual.out
--- /home/bf/bf-build/taipan/HEAD/pgsql/src/test/regress/expected/generated_virtual.out 2026-06-17
07:00:34.298450176+0200
+++ /home/bf/bf-build/taipan/HEAD/pgsql.build/src/test/regress/results/generated_virtual.out 2026-06-17
20:51:26.084674716+0200
@@ -731,9 +731,9 @@
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);
SELECT a, b, c FROM gtest21c;
- a | b | c
-----+----+----
- 10 | 20 | 42
+ a | b | c
+----+----+---
+ 10 | 20 | 0
(1 row)
DROP TABLE gtest21c;
Speculating wildly, I'm wondering about an uninitialized variable that
happens to usually have the right value.
regards, tom lane
