Re: ERROR: multixact X from before cutoff Y found to be still running

Nathan Bossart <bossartn@amazon.com>

From: "Bossart, Nathan" <bossartn@amazon.com>
To: Thomas Munro <thomas.munro@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Cc: "Schneider, Jeremy" <schnjere@amazon.com>, "pgsql-bugs@postgresql.org" <pgsql-bugs@postgresql.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>, "Nasby, Jim" <nasbyj@amazon.com>
Date: 2019-09-17T19:34:45Z
Lists: pgsql-bugs, pgsql-hackers
On 9/6/19, 10:26 AM, "Robert Haas" <robertmhaas@gmail.com> wrote:
> On Thu, Sep 5, 2019 at 4:08 PM Bossart, Nathan <bossartn@amazon.com> wrote:
>> Right, the v2 patch will effectively ramp-down the freezemin as your
>> freeze_max_age gets smaller, while the v1 patch will set the effective
>> freezemin to zero as soon as your multixact age passes the threshold.
>> I think what is unclear to me is whether this ramp-down behavior is
>> the intended functionality or we should be doing something similar to
>> what we do for regular transaction IDs (i.e. force freezemin to zero
>> right after it hits the "oldest xmin is far in the past" threshold).
>> The comment above MultiXactMemberFreezeThreshold() explains things
>> pretty well, but AFAICT it is more geared towards influencing
>> autovacuum scheduling.  I agree that v2 is safer from the standpoint
>> that it changes as little as possible, though.
>
> I don't presently have a view on fixing the actual but here, but I can
> certainly confirm that I intended MultiXactMemberFreezeThreshold() to
> ratchet up the pressure gradually rather than all at once, and my
> suspicion is that this behavior may be good to retain, but I'm not
> sure.

Thanks for the detailed background information.  FWIW I am now in
favor of the v2 patch.

Nathan

Commits

  1. Fix bug that could try to freeze running multixacts.

  2. Teach autovacuum about multixact member wraparound.

  3. Separate multixact freezing parameters from xid's