Thread: Assert failure when CREATE TEMP TABLE
I came across an Assert failure while running sqlancer. The repro query
is
CREATE TEMP TABLE t0 (c0 int4range CHECK ((('')||(0.005014271491241007) NOT IN (upper(''), ((' 9O')||FALSE))) BETWEEN SYMMETRIC (initcap('dj')LIKE(((('EizW~')||t0.c0) COLLATE "en_AG.utf8"))) AND ((((0.18773675)::MONEY) IN (0.52246463::MONEY))AND(t0.c0 BETWEEN SYMMETRIC ((t0.c0+t0.c0)) AND t0.c0)))) USING heap ON COMMIT DROP;
The failure happens in init_toast_snapshot():
/*
* Catalog snapshots can be returned by GetOldestSnapshot() even if not
* registered or active. That easily hides bugs around not having a
* snapshot set up - most of the time there is a valid catalog snapshot.
* So additionally insist that the current snapshot is registered or
* active.
*/
Assert(HaveRegisteredOrActiveSnapshot());
And 'git bisect' says that the first bad commit is 2489d76c, which makes
me confused because the problemed query does not seem to involve
nullingrels stuff.
Thanks
Richard
is
CREATE TEMP TABLE t0 (c0 int4range CHECK ((('')||(0.005014271491241007) NOT IN (upper(''), ((' 9O')||FALSE))) BETWEEN SYMMETRIC (initcap('dj')LIKE(((('EizW~')||t0.c0) COLLATE "en_AG.utf8"))) AND ((((0.18773675)::MONEY) IN (0.52246463::MONEY))AND(t0.c0 BETWEEN SYMMETRIC ((t0.c0+t0.c0)) AND t0.c0)))) USING heap ON COMMIT DROP;
The failure happens in init_toast_snapshot():
/*
* Catalog snapshots can be returned by GetOldestSnapshot() even if not
* registered or active. That easily hides bugs around not having a
* snapshot set up - most of the time there is a valid catalog snapshot.
* So additionally insist that the current snapshot is registered or
* active.
*/
Assert(HaveRegisteredOrActiveSnapshot());
And 'git bisect' says that the first bad commit is 2489d76c, which makes
me confused because the problemed query does not seem to involve
nullingrels stuff.
Thanks
Richard
Richard Guo <guofenglinux@gmail.com> writes:
> I came across an Assert failure while running sqlancer. The repro query
> is
> CREATE TEMP TABLE t0 (c0 int4range CHECK ((('')||(0.005014271491241007) NOT
> IN (upper(''), ((' 9O')||FALSE))) BETWEEN SYMMETRIC
> (initcap('dj')LIKE(((('EizW~')||t0.c0) COLLATE "en_AG.utf8"))) AND
> ((((0.18773675)::MONEY) IN (0.52246463::MONEY))AND(t0.c0 BETWEEN SYMMETRIC
> ((t0.c0+t0.c0)) AND t0.c0)))) USING heap ON COMMIT DROP;
Hmm. AFAICT, the critical thing about this CHECK condition is simply
that it's bulky enough to create an out-of-line toasted "conbin" field
in pg_constraint. When we come to ON COMMIT DROP, we have to delete
the pg_constraint entry and thereby the toast item, and we evidently
lack a snapshot at that point.
> And 'git bisect' says that the first bad commit is 2489d76c, which makes
> me confused because the problemed query does not seem to involve
> nullingrels stuff.
Probably the reason is that addition of nullingrels fields to the Vars
pushed it over the edge of needing to be out-of-line. The test case
is very close to the line as stated --- for example, I found that it
didn't crash if I changed "en_AG.utf8" to "C", and wasted some time
pursuing the idea that the collation had something to do with it.
The crash got much more stable after adding a couple more dummy clauses
to the CHECK condition, and I've also reproduced it with clauses as
straightforward as "c0 < 'very-long-constant'".
regards, tom lane
16.10.2023 18:46, Tom Lane wrote: > Richard Guo <guofenglinux@gmail.com> writes: >> I came across an Assert failure while running sqlancer. The repro query >> is > Hmm. AFAICT, the critical thing about this CHECK condition is simply > that it's bulky enough to create an out-of-line toasted "conbin" field > in pg_constraint. When we come to ON COMMIT DROP, we have to delete > the pg_constraint entry and thereby the toast item, and we evidently > lack a snapshot at that point. That's very similar to bug #18127, and looks like one more case to the collection [1], with RemoveConstraintById() -> CatalogTupleDelete() -> simple_heap_delete() ... https://www.postgresql.org/message-id/9541c507-a325-7768-38b0-90f6532c01e3%40gmail.com Best regards, Alexander
On Mon, Oct 16, 2023 at 11:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Richard Guo <guofenglinux@gmail.com> writes:
> And 'git bisect' says that the first bad commit is 2489d76c, which makes
> me confused because the problemed query does not seem to involve
> nullingrels stuff.
Probably the reason is that addition of nullingrels fields to the Vars
pushed it over the edge of needing to be out-of-line. The test case
is very close to the line as stated --- for example, I found that it
didn't crash if I changed "en_AG.utf8" to "C", and wasted some time
pursuing the idea that the collation had something to do with it.
The crash got much more stable after adding a couple more dummy clauses
to the CHECK condition, and I've also reproduced it with clauses as
straightforward as "c0 < 'very-long-constant'".
Ah, this clears up my confusion. Thanks for the fix.
Thanks
Richard
Thanks
Richard