BUG #17539: Assert after CREATE OPERATOR CLASS command
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:t71383psql -h localhost -U postgresBuilt from patchset v2 (message #2), September 20, 2026 at 11: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 t71383_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 t71383_2 && git checkout t71383_2Patchset v2 (message #2) is on t71383_2
The following bug has been logged on the website:
Bug reference: 17539
Logged by: Dmitry Koval
Email address: d.koval@postgrespro.ru
PostgreSQL version: 14.4
Operating system: Ubuntu 20.04 LTS
Description:
Hi,
PostgreSQL (REL_15_BETA2, REL_14_STABLE etc.) configured with
"--enable-cassert" option triggers Assert when executing a file test.sql:
CREATE FUNCTION my_int4_sort(int4,int4) RETURNS int LANGUAGE sql
AS $$ SELECT CASE WHEN $1 = $2 THEN 0 WHEN $1 > $2 THEN 0 ELSE -1 END;
$$;
CREATE OPERATOR CLASS test_int4_ops FOR TYPE int4 USING btree AS
OPERATOR 5 > (int4,int4), FUNCTION 1 my_int4_sort(int4,int4);
CREATE TABLE partkey_t (a int4) PARTITION BY RANGE (a test_int4_ops);
CREATE TABLE partkey_t_1 PARTITION OF partkey_t FOR VALUES FROM (0) TO
(1000);
INSERT INTO partkey_t VALUES (100);
DROP TABLE partkey_t;
DROP OPERATOR CLASS test_int4_ops USING btree;
DROP FUNCTION my_int4_sort(int4,int4);
PSQL utility prints error:
\i test.sql
CREATE FUNCTION
CREATE OPERATOR CLASS
CREATE TABLE
CREATE TABLE
psql:test.sql:7: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
psql:test.sql:7: error: connection to server was lost
log-file contains a string like this (master branch):
TRAP: FailedAssertion("next_index == nparts", File: "partbounds.c", Line:
891, PID: 87939)
I know that this situation is almost unreal, it was obtained using automated
testing with mixing queries and described in the documentation [1]https://www.postgresql.org/docs/15/sql-createopclass.html:
"CREATE OPERATOR CLASS does not presently check whether the operator class
definition includes all the operators and functions required by the index
method, nor whether the operators and functions form a self-consistent set.
It is the user's responsibility to define a valid operator class."
But probably an error in this case will be better than Assert, especially as
the community fixes situations like this [2]https://git.postgrespro.ru/pgpro-dev/postgrespro/-/commit/cbcea3b91.
(I'll attach file with patch for master branch in next email).
[1]: https://www.postgresql.org/docs/15/sql-createopclass.html
[2]: https://git.postgrespro.ru/pgpro-dev/postgrespro/-/commit/cbcea3b91
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
PG Bug reporting form <noreply@postgresql.org> writes:
CREATE FUNCTION my_int4_sort(int4,int4) RETURNS int LANGUAGE sql
AS $$ SELECT CASE WHEN $1 = $2 THEN 0 WHEN $1 > $2 THEN 0 ELSE -1 END;
$$;
CREATE OPERATOR CLASS test_int4_ops FOR TYPE int4 USING btree AS
OPERATOR 5 > (int4,int4), FUNCTION 1 my_int4_sort(int4,int4);
This is a broken operator class definition (it's missing most of the
expected operators for a btree opclass). It's not exactly surprising
that it causes problems. I have zero desire to try to make the system
bulletproof against incorrectly-made opclasses.
regards, tom lane
On Tue, Jul 05, 2022 at 06:32:22PM -0400, Tom Lane wrote:
This is a broken operator class definition (it's missing most of the
expected operators for a btree opclass). It's not exactly surprising
that it causes problems. I have zero desire to try to make the system
bulletproof against incorrectly-made opclasses.
Agreed. But isn't the proposal of Dmitry to switch the assertion to
an error a good thing though? It is not particularly user-friendly to
just throw an assertion if we could warn at the early stages that
something's wrong.
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
Agreed. But isn't the proposal of Dmitry to switch the assertion to
an error a good thing though?
If you're excited enough about it to commit it, I won't stand in
the way. But I know that there's plenty of other stuff you can
break with a crafted opclass definition.
regards, tom lane