Re: BUG #14941: Vacuum crashes
От
Andres Freund
Тема
Re: BUG #14941: Vacuum crashes
Дата
Msg-id
20180331001946.uie7elezusxes7qw@alap3.anarazel.de
Ответ на
Re: BUG #14941: Vacuum crashes (Bossart, Nathan)
Список
Дерево обсуждения
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Robert Haas <robertmhaas@gmail.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael.paquier@gmail.com>
Re: BUG #14941: Vacuum crashes Lyes Ameddah <lyes.amd@gmail.com>
Re: BUG #14941: Vacuum crashes Robert Haas <robertmhaas@gmail.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael.paquier@gmail.com>
Re: BUG #14941: Vacuum crashes Masahiko Sawada <sawada.mshk@gmail.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Masahiko Sawada <sawada.mshk@gmail.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Masahiko Sawada <sawada.mshk@gmail.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael.paquier@gmail.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael.paquier@gmail.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael.paquier@gmail.com>
Re: BUG #14941: Vacuum crashes Andres Freund <andres@anarazel.de>
Re: BUG #14941: Vacuum crashes Andres Freund <andres@anarazel.de>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael@paquier.xyz>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Andres Freund <andres@anarazel.de>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael@paquier.xyz>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael@paquier.xyz>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael@paquier.xyz>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes Masahiko Sawada <sawada.mshk@gmail.com>
Re: BUG #14941: Vacuum crashes Robert Haas <robertmhaas@gmail.com>
Re: BUG #14941: Vacuum crashes Andres Freund <andres@anarazel.de>
Re: BUG #14941: Vacuum crashes Michael Paquier <michael.paquier@gmail.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Re: BUG #14941: Vacuum crashes "Bossart, Nathan" <bossartn@amazon.com>
Hi,
On 2018-03-30 18:39:01 +0000, Bossart, Nathan wrote:
> I've noticed one more problem with ACCESS EXCLUSIVE. If an ACCESS
> EXCLUSIVE lock is held on a child relation of a partitioned table,
> an ANALYZE on the partitioned table will be blocked at
> acquire_inherited_sample_rows().
>
> static int
> acquire_inherited_sample_rows(Relation onerel, int elevel,
> HeapTuple *rows, int targrows,
> double *totalrows, double *totaldeadrows)
> {
> ...
> /*
> * Find all members of inheritance set. We only need AccessShareLock on
> * the children.
> */
> tableOIDs =
> find_all_inheritors(RelationGetRelid(onerel), AccessShareLock, NULL);
Right.
> It also seems possible for the call to vac_open_indexes() in
> do_analyze_rel() to block.
Yup.
> I think the most straightforward approach for fixing this is to add
> skip-locked functionality in find_all_inheritors(),
> find_inheritance_children(), and vac_open_indexes(), but I am curious
> what others think.
I'm actually wondering if we shouldn't just ignore this problem. While
the other cases VACUUM (SKIP LOCKED) are intended to solve seem common,
these seem less so. But it'd be a bit weird, too..
Could you post a rebased version of the patch, with an incremental
addition of what you propose in a separate patch?
Greetings,
Andres Freund
В списке pgsql-hackers по дате отправления
От: Andres Freund
Дата: