Re: ERROR: multixact X from before cutoff Y found to be still running
От | Bossart, Nathan |
---|---|
Тема | Re: ERROR: multixact X from before cutoff Y found to be still running |
Дата | |
Msg-id | 090A11C7-9EA5-4D78-93B2-99E0D6C2BC0E@amazon.com обсуждение исходный текст |
Ответ на | Re: ERROR: multixact X from before cutoff Y found to be still running (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: ERROR: multixact X from before cutoff Y found to be still running
Re: ERROR: multixact X from before cutoff Y found to be still running |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: