Re: Assert failure when CREATE TEMP TABLE
От | Tom Lane |
---|---|
Тема | Re: Assert failure when CREATE TEMP TABLE |
Дата | |
Msg-id | 2301835.1697471214@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Assert failure when CREATE TEMP TABLE (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: Assert failure when CREATE TEMP TABLE
Re: Assert failure when CREATE TEMP TABLE |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: