From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Assert failure when CREATE TEMP TABLE |
Date: | 2023-10-18 06:57:37 |
Message-ID: | CAMbWs4-VkYarbZsu-dFFo6=J5XgaJX4GDfBqVbGJPO6qrV+iZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Oct 16, 2023 at 11:46 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Richard Guo <guofenglinux(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Flavien GUEDEZ | 2023-10-18 14:21:57 | Insufficient memory access checks in pglz_decompress |
Previous Message | torikoshia | 2023-10-18 06:50:39 | Re: pg_rewind WAL segments deletion pitfall |