Thread: BUG #17539: Assert after CREATE OPERATOR CLASS command

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]: 
"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].

(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

Attachment: patch

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