From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Timothy Garnett <tgarnett(at)panjiva(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Date: | 2015-05-06 10:26:46 |
Message-ID: | CAEepm=2Q_QSLjDBnwqU6cWZk-k_3QvnmVc3JCZCBHfh0BDVb_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, May 6, 2015 at 2:29 PM, Robert Haas <robertmhaas(at)gmail(dot)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
Attachment | Content-Type | Size |
---|---|---|
memberswrap-autovacuum-8.patch | application/octet-stream | 14.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-05-06 10:45:03 | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Previous Message | Sandeep Thakkar | 2015-05-06 06:46:17 | Re: BUG #13240: Error tryping to launch Stack Builder |