BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors
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:t253481psql -h localhost -U postgresBuilt from patchset v2 (message #2), August 23, 2026 at 03:38 PM.
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 t253481_2 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 t253481_2 && git checkout t253481_2Patchset v2 (message #2) is on t253481_2
The following bug has been logged on the website:
Bug reference: 19629
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
Four ereport(ERROR, ...) calls in src/backend/statistics/stat_utils.c
(function stats_fill_fcinfo_from_arg_pairs) are missing errcode(),
causing user input validation errors to return SQLSTATE XX000
(internal_error) instead of proper error codes.
Reproducers (with \set VERBOSITY verbose):
-- 1. Odd number of variadic args (line 372)
SELECT pg_restore_relation_stats('schemaname', 'stats_import', 'relname');
-- ERROR: XX000: variadic arguments must be name/value pairs
-- LOCATION: stats_fill_fcinfo_from_arg_pairs, stat_utils.c:372
-- 2. NULL argument name (line 387)
SELECT pg_restore_relation_stats(
'schemaname', 'stats_import', 'relname', 'test', NULL, '17'::integer);
-- ERROR: XX000: name at variadic position 5 is null
-- LOCATION: stats_fill_fcinfo_from_arg_pairs, stat_utils.c:387
-- 3. Wrong argument name type (line 391)
SELECT pg_restore_relation_stats(42, 'stats_import', 'relname', 'test');
-- ERROR: XX000: name at variadic position 1 has type integer, expected
type text
-- LOCATION: stats_fill_fcinfo_from_arg_pairs, stat_utils.c:391
A fourth site at line 656 has the same missing errcode pattern.
Suggested fix: add errcode() to each ereport call
(ERRCODE_INVALID_PARAMETER_VALUE,
ERRCODE_NULL_VALUE_NOT_ALLOWED, ERRCODE_DATATYPE_MISMATCH respectively).
Found by automated SQL fuzzing.
Credit: Zheng Wang, Yanjie Zhao, Yiyang Liu
On Wed, Aug 19, 2026 at 6:24 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
Suggested fix: add errcode() to each ereport call
(ERRCODE_INVALID_PARAMETER_VALUE,
ERRCODE_NULL_VALUE_NOT_ALLOWED, ERRCODE_DATATYPE_MISMATCH respectively).
Thanks for the report and suggestion!
I agree that these errors should not be reported with SQLSTATE XX000.
Attached is a patch that assigns specific SQLSTATEs to these cases.
The first three use the error codes you suggested. For the fourth case,
"maximum number of statistics slots exceeded", I used
ERRCODE_PROGRAM_LIMIT_EXCEEDED rather than
ERRCODE_INVALID_PARAMETER_VALUE. This is caused by PostgreSQL's fixed
limit on pg_statistic slots, so PROGRAM_LIMIT_EXCEEDED seemed more
appropriate.
I think this should be backpatched to v18, where
pg_restore_relation_stats() and pg_restore_attribute_stats() were
introduced.
Thought?
Regards,
--
Fujii Masao
Attachments:
t253481_2v1-v18-0001-Report-specific-SQLSTATEs-for-stats-restore-error.txttext/plain; charset=US-ASCII; name=v1-v18-0001-Report-specific-SQLSTATEs-for-stats-restore-error.txtDownload+9-6
v1-0001-Report-specific-SQLSTATEs-for-stats-restore-error.patchapplication/octet-stream; name=v1-0001-Report-specific-SQLSTATEs-for-stats-restore-error.patchDownload+9-6
Hi,
On Wed, 19 Aug 2026 at 20:52, Fujii Masao <masao.fujii@gmail.com> wrote:
On Wed, Aug 19, 2026 at 6:24 PM PG Bug reporting form
<noreply@postgresql.org> wrote:Suggested fix: add errcode() to each ereport call
(ERRCODE_INVALID_PARAMETER_VALUE,
ERRCODE_NULL_VALUE_NOT_ALLOWED, ERRCODE_DATATYPE_MISMATCHrespectively).
Thanks for the report and suggestion!
I agree that these errors should not be reported with SQLSTATE XX000.
Attached is a patch that assigns specific SQLSTATEs to these cases.The first three use the error codes you suggested. For the fourth case,
"maximum number of statistics slots exceeded", I used
ERRCODE_PROGRAM_LIMIT_EXCEEDED rather than
ERRCODE_INVALID_PARAMETER_VALUE. This is caused by PostgreSQL's fixed
limit on pg_statistic slots, so PROGRAM_LIMIT_EXCEEDED seemed more
appropriate.I think this should be backpatched to v18, where
pg_restore_relation_stats() and pg_restore_attribute_stats() were
introduced.Thought?
Thanks for the patch, Fujii-san!
I had posted a patch for all the three related bugs at [0]/messages/by-id/CAJTYsWWpwHsvzKp0JPvGbWttXrOafMCtmGBBQs6bhCKn88fgug@mail.gmail.com
Found some more places where the issue exists and added
there. Maybe you can incorporate those too in your patch?
Regards,
Ayush
[0]: /messages/by-id/CAJTYsWWpwHsvzKp0JPvGbWttXrOafMCtmGBBQs6bhCKn88fgug@mail.gmail.com
/messages/by-id/CAJTYsWWpwHsvzKp0JPvGbWttXrOafMCtmGBBQs6bhCKn88fgug@mail.gmail.com
Hi,
On Wed, 19 Aug 2026 at 21:42, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
wrote:
Hi,
On Wed, 19 Aug 2026 at 20:52, Fujii Masao <masao.fujii@gmail.com> wrote:
On Wed, Aug 19, 2026 at 6:24 PM PG Bug reporting form
<noreply@postgresql.org> wrote:Suggested fix: add errcode() to each ereport call
(ERRCODE_INVALID_PARAMETER_VALUE,
ERRCODE_NULL_VALUE_NOT_ALLOWED, ERRCODE_DATATYPE_MISMATCHrespectively).
Thanks for the report and suggestion!
I agree that these errors should not be reported with SQLSTATE XX000.
Attached is a patch that assigns specific SQLSTATEs to these cases.The first three use the error codes you suggested. For the fourth case,
"maximum number of statistics slots exceeded", I used
ERRCODE_PROGRAM_LIMIT_EXCEEDED rather than
ERRCODE_INVALID_PARAMETER_VALUE. This is caused by PostgreSQL's fixed
limit on pg_statistic slots, so PROGRAM_LIMIT_EXCEEDED seemed more
appropriate.I think this should be backpatched to v18, where
pg_restore_relation_stats() and pg_restore_attribute_stats() were
introduced.Thought?
Thanks for the patch, Fujii-san!
I had posted a patch for all the three related bugs at [0]
Found some more places where the issue exists and added
there. Maybe you can incorporate those too in your patch?
Updating link for [0]/messages/by-id/CAJTYsWUuL1cvBrameN2r-n6k8Ju8nqymJVeamaf+1FDneTxRLw@mail.gmail.com </messages/by-id/CAJTYsWUuL1cvBrameN2r-n6k8Ju8nqymJVeamaf+1FDneTxRLw@mail.gmail.com> to the all-in [19629-19632 thread]
Regards,
Ayush
[0]: /messages/by-id/CAJTYsWUuL1cvBrameN2r-n6k8Ju8nqymJVeamaf+1FDneTxRLw@mail.gmail.com </messages/by-id/CAJTYsWUuL1cvBrameN2r-n6k8Ju8nqymJVeamaf+1FDneTxRLw@mail.gmail.com>
/messages/by-id/CAJTYsWUuL1cvBrameN2r-n6k8Ju8nqymJVeamaf+1FDneTxRLw@mail.gmail.com
</messages/by-id/CAJTYsWUuL1cvBrameN2r-n6k8Ju8nqymJVeamaf+1FDneTxRLw@mail.gmail.com>
On Wed, Aug 19, 2026 at 09:42:18PM +0530, Ayush Tiwari wrote:
On Wed, 19 Aug 2026 at 20:52, Fujii Masao <masao.fujii@gmail.com> wrote:
I think this should be backpatched to v18, where
pg_restore_relation_stats() and pg_restore_attribute_stats() were
introduced.Thought?
Adding an errcode() is a life improvement thing. So, while I agree
that the proposed patch is an improvement, I don't see a strong need
for a backpatch. Feel free to override this argument as you feel, of
course.
Just a note: I've tried to be careful with assigning errcodes for all
the new error paths of extended_stats_funcs.c added in v19 that can be
reached by SQL. If there are holes in there, please let me know.
Found some more places where the issue exists and added
there. Maybe you can incorporate those too in your patch?
I'd suggest to keep things isolated in their own fashion, as they
address different areas with slightly different user-changes changes
(okay, not much).
--
Michael
Hi,
On Fri, 21 Aug 2026 at 04:00, Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Aug 19, 2026 at 09:42:18PM +0530, Ayush Tiwari wrote:
On Wed, 19 Aug 2026 at 20:52, Fujii Masao <masao.fujii@gmail.com> wrote:
I think this should be backpatched to v18, where
pg_restore_relation_stats() and pg_restore_attribute_stats() were
introduced.Thought?
Adding an errcode() is a life improvement thing. So, while I agree
that the proposed patch is an improvement, I don't see a strong need
for a backpatch. Feel free to override this argument as you feel, of
course.
FWIW I think it's more of a bug too rather than just improvement
some of the applications depend on the errcode PG emits
to give end results.
Just a note: I've tried to be careful with assigning errcodes for all
the new error paths of extended_stats_funcs.c added in v19 that can be
reached by SQL. If there are holes in there, please let me know.Found some more places where the issue exists and added
there. Maybe you can incorporate those too in your patch?I'd suggest to keep things isolated in their own fashion, as they
address different areas with slightly different user-changes changes
(okay, not much).
Ahh atleast for 19629-31 I thought they shared the exact root cause
of not specified errcodes, and there were few more in the tree, but
I'm fine with the splitting part if needed.
Regards,
Ayush
On Fri, Aug 21, 2026 at 7:30 AM Michael Paquier <michael@paquier.xyz> wrote:
Adding an errcode() is a life improvement thing. So, while I agree
that the proposed patch is an improvement, I don't see a strong need
for a backpatch. Feel free to override this argument as you feel, of
course.
I understand your point, but I'm inclined to backpatch this to v18.
These are input-validation errors that are directly reachable from SQL,
and the SQLSTATE is exposed to applications. Since applications commonly
branch on SQLSTATE, reporting XX000 makes these errors look like internal
errors rather than invalid input. That seems more like a bug than
a cosmetic improvement to me.
Also, these functions were introduced in v18, so the risk of breaking
existing applications that depend on the current XX000 behavior should
be low. For these reasons, I think backpatching to v18 is preferable here.
Thoughts?
But, on the other hand, if we want to avoid breaking existing
applications that depend on the current XX000 behavior, backpatching
to v19 might be a reasonable alternative.
I'd suggest to keep things isolated in their own fashion, as they
address different areas with slightly different user-changes changes
(okay, not much).
+1
Regards,
--
Fujii Masao