Re: pg11.1 jit segv
| От | Andres Freund |
|---|---|
| Тема | Re: pg11.1 jit segv |
| Дата | |
| Msg-id | 20181127082655.46oqlo7wdnvak4g7@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: pg11.1 jit segv (Justin Pryzby <pryzby@telsasoft.com>) |
| Ответы |
Re: pg11.1 jit segv
|
| Список | 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.
Вложения
В списке pgsql-hackers по дате отправления: