BUG #19631: currtid2() on a view with GROUP BY ctid crashes with XX000
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253483psql -h localhost -U postgresBuilt from patchset v3 (message #3), August 23, 2026 at 10:28 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253483_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253483_3 && git checkout t253483_3Patchset v3 (message #3) is on t253483_3
The following bug has been logged on the website:
Bug reference: 19631
Logged by: Zheng Hacker
Email address: hackerzheng666@gmail.com
PostgreSQL version: 19beta3
Operating system: Linux x86_64
Description:
PostgreSQL version: 20devel (commit bdbf662, 2026-08-19)
OS: Linux x86_64
Calling currtid2() on a view whose SELECT includes ctid in a GROUP BY
hits elog(ERROR) without errcode() in tid.c, producing SQLSTATE XX000.
Reproducer:
CREATE TABLE tid_tab (a int);
INSERT INTO tid_tab VALUES (1);
CREATE VIEW tid_view_with_ctid AS
SELECT ctid, a FROM tid_tab GROUP BY ctid, a;
SELECT currtid2('tid_view_with_ctid'::text, '(0,1)'::tid);
-- ERROR: XX000: currtid cannot handle this view
-- LOCATION: currtid_for_view, tid.c:435
Note: the view has a ctid column (so it passes the tididx check at
line 389 which does have a proper errcode), but the GROUP BY prevents
the code from resolving the TLE to a simple base-table Var, so it
falls through to the elog(ERROR) at line 435 which lacks errcode().
Expected: a proper SQLSTATE (e.g. 0A000 feature_not_supported).
Found by automated SQL fuzzing.
Credit: Zheng Wang, Yanjie Zhao, Yiyang Liu
Hi,
On Wed, 19 Aug 2026 at 14:54, PG Bug reporting form <noreply@postgresql.org>
wrote:
The following bug has been logged on the website:
Bug reference: 19631
Logged by: Zheng Hacker
Email address: hackerzheng666@gmail.com
PostgreSQL version: 19beta3
Operating system: Linux x86_64
Description:PostgreSQL version: 20devel (commit bdbf662, 2026-08-19)
OS: Linux x86_64Calling currtid2() on a view whose SELECT includes ctid in a GROUP BY
hits elog(ERROR) without errcode() in tid.c, producing SQLSTATE XX000.Reproducer:
CREATE TABLE tid_tab (a int);
INSERT INTO tid_tab VALUES (1);
CREATE VIEW tid_view_with_ctid AS
SELECT ctid, a FROM tid_tab GROUP BY ctid, a;
SELECT currtid2('tid_view_with_ctid'::text, '(0,1)'::tid);
-- ERROR: XX000: currtid cannot handle this view
-- LOCATION: currtid_for_view, tid.c:435Note: the view has a ctid column (so it passes the tididx check at
line 389 which does have a proper errcode), but the GROUP BY prevents
the code from resolving the TLE to a simple base-table Var, so it
falls through to the elog(ERROR) at line 435 which lacks errcode().Expected: a proper SQLSTATE (e.g. 0A000 feature_not_supported).
Found by automated SQL fuzzing.
Credit: Zheng Wang, Yanjie Zhao, Yiyang Liu
Thanks for the reports. #19629, #19630 and #19631 share one cause: an
error ordinary SQL can reach is raised without an errcode(), so the user
sees XX000.
I scanned the backend for the same pattern, and the attached patch fixes
those three plus four more sites with the same problem: unicode_assigned()
on a non-UTF8 encoding, the pg_control_*() CRC check, a GiST tuple marked
invalid, and ALTER COLLATION ... REFRESH VERSION on "default".
Regards,
Ayush
Hi,
On Wed, 19 Aug 2026 at 16:16, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
wrote:
Hi,
On Wed, 19 Aug 2026 at 14:54, PG Bug reporting form <
noreply@postgresql.org> wrote:The following bug has been logged on the website:
Bug reference: 19631
Logged by: Zheng Hacker
Email address: hackerzheng666@gmail.com
PostgreSQL version: 19beta3
Operating system: Linux x86_64
Description:PostgreSQL version: 20devel (commit bdbf662, 2026-08-19)
OS: Linux x86_64Calling currtid2() on a view whose SELECT includes ctid in a GROUP BY
hits elog(ERROR) without errcode() in tid.c, producing SQLSTATE XX000.Reproducer:
CREATE TABLE tid_tab (a int);
INSERT INTO tid_tab VALUES (1);
CREATE VIEW tid_view_with_ctid AS
SELECT ctid, a FROM tid_tab GROUP BY ctid, a;
SELECT currtid2('tid_view_with_ctid'::text, '(0,1)'::tid);
-- ERROR: XX000: currtid cannot handle this view
-- LOCATION: currtid_for_view, tid.c:435Note: the view has a ctid column (so it passes the tididx check at
line 389 which does have a proper errcode), but the GROUP BY prevents
the code from resolving the TLE to a simple base-table Var, so it
falls through to the elog(ERROR) at line 435 which lacks errcode().Expected: a proper SQLSTATE (e.g. 0A000 feature_not_supported).
Found by automated SQL fuzzing.
Credit: Zheng Wang, Yanjie Zhao, Yiyang LiuThanks for the reports. #19629, #19630 and #19631 share one cause: an
error ordinary SQL can reach is raised without an errcode(), so the user
sees XX000.I scanned the backend for the same pattern, and the attached patch fixes
those three plus four more sites with the same problem: unicode_assigned()
on a non-UTF8 encoding, the pg_control_*() CRC check, a GiST tuple marked
invalid, and ALTER COLLATION ... REFRESH VERSION on "default".
Attaching new patch addressing just #19631 along with
rest files mentioned upthread.
Regards,
Ayush