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

On May 6, 2015, at 9:48 PM, Thomas Munro <thomas.munro@enterprisedb.com> wro=
te:
>> On Thu, May 7, 2015 at 4:23 AM, Robert Haas <robertmhaas@gmail.com> wrote=
:
>> On Wed, May 6, 2015 at 10:34 AM, Alvaro Herrera <alvherre@2ndquadrant.com=
> wrote:
>>>> 2. Doesn't the code that sets MultiXactState->multiVacLimit also need
>>>> to use what I'm now calling MultiXactMemberFreezeThreshold() - or some
>>>> similar logic?  Otherwise, a user with autovacuum=3Doff won't get
>>>> emergency autovacuums for member exhaustion, even though they will get
>>>> them for offset exhaustion.
>>>=20
>>> Yeah, it looks like it does.
>>=20
>> OK, I'm not clear how to do that correctly, exactly, but hopefully one
>> of us can figure that out.
>=20
> MultiXactState->multiVacLimit holds the multixact IDs at which an age
> thresholds will be crossed, so that GetNewMultiXactId can check it
> cheaply.  But we can't predict the future multixact IDs at which our
> member usage threshold will be crossed.  We could try to estimate it
> based on past multixact sizes, but (as I think we already covered
> somewhere else) we shouldn't be trying to do that because it wouldn't
> handle the situation where your member space consumption rate suddenly
> went up, among other problems.
>=20
> How about this:  we add oldestOffset to MultiXactState, to be set by
> DetermineSafeOldestOffset, and then at the place where
> GetNewMultiXactId checks if (!MultiXactIdPrecedes(result,
> MultiXactState->multiVacLimit) it could also check whether (nextOffset
> - MultiXactState->oldestOffset > MULTIXACT_MEMBER_SAFE_THRESHOLD).
> ReadMultiXactCounts should also use the oldestOffset value directly
> from shmem instead of calling find_multixact_start.

That sounds pretty good.

...Robert=