pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17539: Assert after CREATE OPERATOR CLASS command
5+ messages / 4 participants
[nested] [flat]
* BUG #17539: Assert after CREATE OPERATOR CLASS command
@ 2022-07-05 20:08 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 2 replies; 5+ messages in thread
From: PG Bug reporting form @ 2022-07-05 20:08 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: d.koval@postgrespro.ru
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #17539: Assert after CREATE OPERATOR CLASS command
@ 2022-07-05 20:36 Dmitry Koval <d.koval@postgrespro.ru>
parent: PG Bug reporting form <noreply@postgresql.org>
1 sibling, 0 replies; 5+ messages in thread
From: Dmitry Koval @ 2022-07-05 20:36 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org
Attachment: patch
Attachments:
v1-0001-error-instead-assert.patch (text/plain, 1004B) download
diff --git a/src/backend/partitioning/partbounds.c b/src/backend/partitioning/partbounds.c
index 6b35111ebb6..21b10d29a50 100644
--- a/src/backend/partitioning/partbounds.c
+++ b/src/backend/partitioning/partbounds.c
@@ -673,7 +673,11 @@ create_list_bounds(PartitionBoundSpec **boundspecs, int nparts,
/* All partitions must now have been assigned canonical indexes. */
- Assert(next_index == nparts);
+ if (next_index != nparts)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
+ errmsg("not all partitions assigned canonical indexes")));
+
return boundinfo;
}
@@ -888,7 +892,11 @@ create_range_bounds(PartitionBoundSpec **boundspecs, int nparts,
boundinfo->indexes[i] = -1;
/* All partitions must now have been assigned canonical indexes. */
- Assert(next_index == nparts);
+ if (next_index != nparts)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
+ errmsg("not all partitions assigned canonical indexes")));
+
return boundinfo;
}
* Re: BUG #17539: Assert after CREATE OPERATOR CLASS command
@ 2022-07-05 22:32 Tom Lane <tgl@sss.pgh.pa.us>
parent: PG Bug reporting form <noreply@postgresql.org>
1 sibling, 1 reply; 5+ messages in thread
From: Tom Lane @ 2022-07-05 22:32 UTC (permalink / raw)
To: d.koval@postgrespro.ru; +Cc: pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #17539: Assert after CREATE OPERATOR CLASS command
@ 2022-07-06 03:41 Michael Paquier <michael@paquier.xyz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Michael Paquier @ 2022-07-06 03:41 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: d.koval@postgrespro.ru; pgsql-bugs@lists.postgresql.org
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
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: BUG #17539: Assert after CREATE OPERATOR CLASS command
@ 2022-07-06 03:56 Tom Lane <tgl@sss.pgh.pa.us>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 5+ messages in thread
From: Tom Lane @ 2022-07-06 03:56 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: d.koval@postgrespro.ru; pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2022-07-06 03:56 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-07-05 20:08 BUG #17539: Assert after CREATE OPERATOR CLASS command PG Bug reporting form <noreply@postgresql.org>
2022-07-05 20:36 ` Dmitry Koval <d.koval@postgrespro.ru>
2022-07-05 22:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-07-06 03:41 ` Michael Paquier <michael@paquier.xyz>
2022-07-06 03:56 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox