Re: GIN fast insert database hang

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: GIN fast insert database hang
Дата
Msg-id 603c8f070902112014v315b0dcam3542570ca361caac@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GIN fast insert database hang  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: GIN fast insert database hang
Список pgsql-hackers
> I did this four times, sometimes with the variant of adding "set
> enable_bitmapscan to false;" before the explain analyze.  In three
> cases the database recovered succesfully after the immediate shutdown;
> in the other case, it crapped out much as described in my original
> email.

Sorry to keep replying to myself, but I've figured that autovacuum is
not required to trigger this bug.  In fact, I can reliably trigger it
much more quickly just by starting two concurrent copies of:

psql -c "insert into foo (x) select array[(random() * 100)::int,
(random() * 90)::int, (random()*80)::int] from
generate_series(1,100000);"

This freezes the whole system even with autovacuum = off in
postgresql.conf.  As before, the backends wait on a semop() call.

I was able to reproduce the recovery failure this way once as well,
but that part of the problem seems to be much more erratic.  Most of
the time after an immediate shutdown, pg_ctl start triggers recovery
followed by normal startup.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: GIN fast insert database hang
Следующее
От: Tom Lane
Дата:
Сообщение: Re: advance local xmin more aggressively