Re: Berserk Autovacuum (let's save next Mandrill)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Berserk Autovacuum (let's save next Mandrill)
Дата
Msg-id 30041.1585689399@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Berserk Autovacuum (let's save next Mandrill)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Berserk Autovacuum (let's save next Mandrill)
Список pgsql-hackers
I wrote:
> Dean Rasheed <dean.a.rasheed@gmail.com> writes:
>> I had a go at reproducing this. I wasn't able to produce the reported
>> failure, but I can reliably produce an Assert failure that may be
>> related by doing a VACUUM FULL simultaneously with an ANALYZE that is
>> generating extended stats, which produces:
>> ...
>> It looks to me as though the problem is that statext_store() needs to
>> take its lock on pg_statistic_ext_data *before* searching for the
>> stats tuple to update.

> Hmm, yeah, that seems like clearly a bad idea.

I pushed a fix for that, but I think it must be unrelated to the
buildfarm failures we're seeing.  For that coding to be a problem,
it would have to run concurrently with a VACUUM FULL or CLUSTER
on pg_statistic_ext_data (which would give all the tuples new TIDs).
AFAICS that won't happen with the tests that are giving trouble.

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Rethinking opclass member checks and dependency strength
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Rethinking opclass member checks and dependency strength