Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
Дата
Msg-id CAEepm=2Q_QSLjDBnwqU6cWZk-k_3QvnmVc3JCZCBHfh0BDVb_A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)  (Robert Haas <robertmhaas@gmail.com>)
Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-bugs
On Wed, May 6, 2015 at 2:29 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> + * Based on the assumption that there is no reasonable way for an end user to
> + * configure the thresholds for this, we define the safe member count to be
> + * half of the member address space, and the dangerous level to be
>
> but:
>
> +       const MultiXactOffset safe_member_count = MaxMultiXactOffset / 4;
>
> Those don't match. [...]

Fixed/obsoleted in the attached patch.  It has a dynamic
safe_member_count based on scaling the GUC as described in my earlier
email with the v7 patch; the behaviour with the default GUC value
works out to a similar safe_member_count value, but this way it can be
changed if needed, and we don't introduce any new GUCs.  Also, since
the GUC used in determining safe_member_count is either
autovacuum_multixact_freeze_max_age or vacuum_multixact_freeze_max_age
depending on which kind of vacuum it is, that is now a parameter
passed into MultiXactCheckMemberUsage, so safe_member_count is no
longer a constant.

> [...] Also, we usually use #define rather than const for
> constants.  I suggest we do that here, too.

Done for DANGEROUS_MEMBER_COUNT and AVG_MULTIXACT_SIZE_THRESHOLD which
are still constants.

> +               int safe_multixact_age = MultiXactCheckMemberUsage();
> +               if (safe_multixact_age >= 0)
>
> Project style is to leave a blank line between these, I think.

Done.

> I think you need to update the comments for relation_needs_vacanalyze().

Done.

> The documentation in section 23.1.5.1, "Multixacts and Wraparound",
> also needs updating.

Done.  I also rewrote some of the commentary in
MultiXactCheckMemberUsage, to try to make the theory behind the ramp
up algorithm clearer.

I will do some more testing.  Does anyone have any feedback on the
choice of value for AVG_MULTIXACT_SIZE_THRESHOLD, or real world data
on average multixact sizes, or see more general problems?  The idea
here is that you should only see autovacuum behaviour change if it's
more than AVG_MULTIXACT_SIZE_THRESHOLD.

--
Thomas Munro
http://www.enterprisedb.com

Вложения

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

Предыдущее
От: Sandeep Thakkar
Дата:
Сообщение: Re: BUG #13240: Error tryping to launch Stack Builder
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)