From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: pgsql-bugs@postgresql.org
Subject: Re: Assert failure when CREATE TEMP TABLE
In-reply-to: 
 <CAMbWs4-x26=_QxxgdJyNbiCDzvtr2WV5ZDso_v-CukKEe6cBZw@mail.gmail.com>
References: 
 <CAMbWs4-x26=_QxxgdJyNbiCDzvtr2WV5ZDso_v-CukKEe6cBZw@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Mon, 16 Oct 2023 19:02:29 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2301834.1697471214.1@sss.pgh.pa.us>
Date: Mon, 16 Oct 2023 11:46:54 -0400
Message-ID: <2301835.1697471214@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2301835.1697471214%40sss.pgh.pa.us>
Precedence: bulk

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