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  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Edmund Horner
Дата:
Сообщение: Re: Tid scan improvements
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Remove Deprecated Exclusive Backup Mode