Bug - DoS - Handler function lookups consider non-handler functions
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:t51278psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 09:47 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 t51278_1 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 t51278_1 && git checkout t51278_1Patchset v1 (message #1) is on t51278_1
Today:
create extension tsm_system_rows ;
create schema s1;
create function s1.system_rows(internal) returns void language c as
'tsm_system_rows.so', 'tsm_system_rows_handler';
set search_path to s1,public,pg_catalog;
select count(*) from pg_class tablesample system_rows(0);
ERROR: function system_rows must return type tsm_handler
LINE 1: select count(*) from pg_class tablesample system_rows(0);
The above is a denial-of-service due to our decision to lookup handler
functions by name regardless of return type and consider it an error if a
function with the wrong return type shows up (in particular, even though
one with the correct signature exists and otherwise would have been found).
The attached POC fixes this by allowing callers to also specify the OID of
the handler type as part of their function lookup criteria. Tablesample is
fixed to use this new call though possibly others exist. I'm not
particularly fond of what I ended up with naming conventions but figure
it's good enough for now.
Patch applied and re-running the above:
select count(*) from pg_class tablesample system_rows(0);
count
-------
0
(1 row)
I noticed this when reviewing the extensible copy formats patch which used
tablesample as a reference.
David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
create extension tsm_system_rows ;
create schema s1;
create function s1.system_rows(internal) returns void language c as
'tsm_system_rows.so', 'tsm_system_rows_handler';
set search_path to s1,public,pg_catalog;
select count(*) from pg_class tablesample system_rows(0);
ERROR: function system_rows must return type tsm_handler
LINE 1: select count(*) from pg_class tablesample system_rows(0);
The above is a denial-of-service due to our decision to lookup handler
functions by name regardless of return type and consider it an error if a
function with the wrong return type shows up (in particular, even though
one with the correct signature exists and otherwise would have been found).
I do not think this is a bug: it's superuser error. Yeah, it'd be
great if we could prevent people from creating incorrect support
functions, but that'd require solving the halting problem.
The attached POC fixes this by allowing callers to also specify the OID of
the handler type as part of their function lookup criteria.
I'm not on board with that at all. The law of unintended consequences
comes into play the moment you start messing with function lookup
rules. And I'm not at all convinced that "ignore it" is an
improvement over "throw an error".
And please, let's stop with the scare tactics of calling this sort
of thing a denial-of-service.
regards, tom lane