From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg11.1 jit segv |
Date: | 2018-11-27 08:26:55 |
Message-ID: | 20181127082655.46oqlo7wdnvak4g7@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-11-26 22:56:09 -0600, Justin Pryzby wrote:
> On Mon, Nov 26, 2018 at 07:00:35PM -0800, Andres Freund wrote:
> > Could you check that the attached patch this also fixes your original
> > issue? Going through the code to see if there's other occurances of
> > this.
>
> Confirmed that fixes my crash.
Thanks a lot for narrowing down your crash to something I can reproduce!
Here's a more complete patch, with a testcase.
Tom, the test creates a 1100k column table (using \set ECHO none +
gexec), but with a small row. Currently it's not dropped after the
table, as I thought it might be worthwhile to be tested by
pg_dump/upgrade etc too. You're probably the person most concerned with
test runtimes, ... Any concerns about that? The table creation is
quick*, on the order of 30ms.
Greetings,
Andres Freund
*at least as long as there's no default columns and the table's not
dropped, seems we have somewhat of an O(N^2) situation going on when
dropping a table with many columns that have default columns - we
re-build the cache entry after each dropped default value. But as the
max is 1600 columns, that's not too bad.
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Fix-jit-compilation-issue-on-very-wide-tables.patch | text/x-diff | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2018-11-27 08:33:30 | Re: Remove Deprecated Exclusive Backup Mode |
Previous Message | Edmund Horner | 2018-11-27 08:16:46 | Re: Tid scan improvements |