BUG #17539: Assert after CREATE OPERATOR CLASS command

Started by PG Bug reporting formalmost 4 years ago5 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

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

#2Dmitry Koval
d.koval@postgrespro.ru
In reply to: PG Bug reporting form (#1)
Re: BUG #17539: Assert after CREATE OPERATOR CLASS command

Attachment: patch

Attachments:

v1-0001-error-instead-assert.patchtext/plain; charset=UTF-8; name=v1-0001-error-instead-assert.patchDownload+10-2
#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: PG Bug reporting form (#1)
Re: BUG #17539: Assert after CREATE OPERATOR CLASS command

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

#4Michael Paquier
michael@paquier.xyz
In reply to: Tom Lane (#3)
Re: BUG #17539: Assert after CREATE OPERATOR CLASS command

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

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Paquier (#4)
Re: BUG #17539: Assert after CREATE OPERATOR CLASS command

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