Residual tsquery cleanups

Trying an pg_upgrade from pg19 source build (from februari 2026) to pg19-beta3
Environment: Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-137-generic aarch64) fully patched and updated,
running inside a UTM (qemu) VM on apple-silicon M4.

moved the older build and data to *-bku directories, did the whole configure compile install dance including
contrib/pg_stat_statements , contrib/auto_explain and contrib/pgcrypto
initdb went ok,
but on
$PGBIN/pg_upgrade --new-datadir $PGDATA --old-datadir ~/pg-data-bku/ --new-bindir $PGBIN --old-bindir ~/pg-install-bku/bin —link
I get

Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database connection settings ok
Checking for unsupported encodings ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking logical replication slots ok
Checking subscription state ok
Checking data type usage ok
Checking for objects affected by Unicode update ok
Creating dump of global objects ok
Creating dump of database schemas
test
*failure*

Consult the last few lines of "/home/ellert/pg-data/pg_upgrade_output.d/20260816T162150.180/log/pg_upgrade_dump_16384.log" for
the probable cause of the failure.
Failure, exiting

contents of the log file:

command: "/home/ellert/pg-install/bin/pg_dump" --host /home/ellert --port 50432 --username ellert --no-data --sequence-data --quote-all-identifiers --binary-upgrade --format=custom --statistics --no-sync --file="/home/ellert/pg-data/pg_upgrade_output.d/20260816T162150.180/dump/pg_upgrade_dump_16384.custom" 'dbname=test' >> "/home/ellert/pg-data/pg_upgrade_output.d/20260816T162150.180/log/pg_upgrade_dump_16384.log" 2>&1
pg_dump: error: query failed: ERROR: column s.tableid does not exist
LINE 2: ...unnest($1) WITH ORDINALITY AS u (tableid, ord) ON s.tableid ...
^
HINT: Perhaps you meant to reference the column "u.tableid".
pg_dump: detail: Query was: PREPARE getAttributeStats(pg_catalog.oid[]) AS
SELECT s.schemaname, s.tablename, s.attname, s.inherited, s.null_frac, s.avg_width, s.n_distinct, s.most_common_vals, s.most_common_freqs, s.histogram_bounds, s.correlation, s.most_common_elems, s.most_common_elem_freqs, s.elem_count_histogram, s.range_length_histogram, s.range_empty_frac, s.range_bounds_histogram FROM pg_catalog.pg_stats s JOIN unnest($1) WITH ORDINALITY AS u (tableid, ord) ON s.tableid = u.tableid ORDER BY u.ord, s.attname, s.inherited

A quick google search finds the offending piece of SQL possibly in the source of pg_dump.c.
Have i encountered an actual issue, or is it me ?

mailinglists <lists@database.one> writes:

Trying an pg_upgrade from pg19 source build (from februari 2026) to pg19-beta3

Yeah, you're outta luck on that one. pg_stats gained a tableid column
sometime after February, but pg_dump will try to use the column
anytime the source server reports itself as v19 or newer. There's no
provision in there for distinguishing different development versions.

I think you can get your data out by using pg_dump or pg_upgrade with
--no-statistics. In general though, keeping important data in a
development version is highly not recommended.

regards, tom lane

Ah i see, thanks !

Ellert.

On Aug 17, 2026, at 00:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The two attached, pretty trivial patches clean up some loose ends
from the recent tsvector/tsquery security commits. I'm thinking
of back-patching both, but perhaps there is an argument for not
back-patching the first one?

regards, tom lane

Overall looks good to me. A few small comments:

1 - 0001
```
+				unsigned int dist = pq_getmsgint(buf, sizeof(int16));
+
+				if (dist > MAXENTRYPOS)
+					elog(ERROR, "invalid tsquery: invalid phrase distance %d",
+						 dist);
```

Here, “dist” is an unsigned int, so maybe it would be better to use “%u” than “%d” to print it.

2 - 0002
···
+     <para>The length of a <type>tsquery</type>'s data (lexemes only)
+     must be less than 1 megabyte</para>
···

Look like to me this is inaccurate, because in pushValue_internal(), the "if (distance > MAXSTRPOS)” check happens before adding a new element, thus distance may exceed MAXSTRPOS after the element is added.

The doc also says the length of a tsvector must be less than 1 MB, which seems correct, because tsvectorin() checks "if (buflen > MAXSTRPOS)” after the final data length has been calculated.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Chao Li <li.evan.chao@gmail.com> writes:

Overall looks good to me. A few small comments:

1 - 0001
```
+				unsigned int dist = pq_getmsgint(buf, sizeof(int16));
+
+				if (dist > MAXENTRYPOS)
+					elog(ERROR, "invalid tsquery: invalid phrase distance %d",
+						 dist);
```

Here, “dist” is an unsigned int, so maybe it would be better to use “%u” than “%d” to print it.

Hmm ... doesn't really matter, since pq_getmsgint's result is
guaranteed to be in 0..65535. But OK.

2 - 0002
···
+     <para>The length of a <type>tsquery</type>'s data (lexemes only)
+     must be less than 1 megabyte</para>
···

Look like to me this is inaccurate, because in pushValue_internal(), the "if (distance > MAXSTRPOS)” check happens before adding a new element, thus distance may exceed MAXSTRPOS after the element is added.

True, it can be up to one lexeme more. But I didn't think it was
worth trying to go into that much detail. As a comparison point,
the corresponding bullet for tsvector doesn't explain how to calculate
the space used for lexeme positions. I think the main takeaway here
is just that there *is* a limit of this type. People who really want
to know the exact details can consult the source code.

regards, tom lane