Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process
Дата
Msg-id 20140619235957.GG16260@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-bugs
Hi Heikki, all,

On 2014-06-09 16:04:06 +0300, Heikki Linnakangas wrote:
> On 06/09/2014 03:46 PM, Andres Freund wrote:
> >>>I haven't thought particularly much about this, but I don't really see
> >>>why the heap_page_is_all_visible() bit needs to be in a critical
> >>>section? Can't we just do that entire bit after the log_heap_clean()?
> >>>Then the heap_page_is_all_visible() can be done outside a critical
> >>>section.
> >Before I start working on a patch along those lines, do you see any
> >problems with making the critical section smaller?
>
> One subtle difference is that the PD_ALL_VISIBLE flag will not be included
> in the full-page-image that log_heap_page() might take. But that seems OK.
> visibilitymap_set() writes a WAL record that sets it at replay.

Heikki, you've changed things around a bit in 2a8e1ac598. That commit
message mentions that there's still a difference in which order things
happen on the master vs. the standby. Am I seeing it correctly that
reordering things like hinted at above (and in the attached patch) fully
gets rid of that problem? And doesn't reintroduce what you fixed?

I've verified that the crash occurs without the patch and doesn't with
it applied. I'm too tired right now to think enough about my fix to push
it.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Вложения

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts