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 по дате отправления: