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)
Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Список | 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 по дате отправления: