On Thu, Oct 17, 2019 at 6:11 AM Jeremy Schneider wrote:
> On 10/16/19 10:09, Bossart, Nathan wrote:
> > On 10/15/19, 11:11 PM, "Thomas Munro" wrote:
> >> Here's a version with a proposed commit message and a comment. Please
> >> let me know if I credited things to the right people!
> >
> > Looks
On 10/15/19, 11:11 PM, "Thomas Munro" wrote:
> Here's a version with a proposed commit message and a comment. Please
> let me know if I credited things to the right people!
Looks good to me. Thanks!
Nathan
On Wed, Sep 18, 2019 at 8:11 AM Bossart, Nathan wrote:
> Thanks for the detailed background information. FWIW I am now in
> favor of the v2 patch.
Here's a version with a proposed commit message and a comment. Please
let me know if I credited things to the right people!
0001-Fix-bug-that-coul
On 9/6/19, 10:26 AM, "Robert Haas" wrote:
> On Thu, Sep 5, 2019 at 4:08 PM Bossart, Nathan 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 pa
On Thu, Sep 5, 2019 at 4:08 PM Bossart, Nathan 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
On Sat, Sep 7, 2019 at 5:25 AM Robert Haas wrote:
> (I apologize if any of the above sounds like I'm talking credit for
> work actually done by Thomas, who I see is listed as the primary
> author of the commit in question. I feel like I invented
> MultiXactMemberFreezeThreshold and the big commen
On Fri, Sep 6, 2019 at 6:32 AM Jeremy Schneider wrote:
> It really appears that it was the autovacuum process itself that was
> providing the oldest running multixact which caused errors on yesterday's
> attempts to vacuum other tables - even though I though vacuum processes were
> ignored by t
On 9/4/19, 9:03 PM, "Thomas Munro" wrote:
> Both patches prevent mxactLimit from being newer than the oldest
> running multixact. The v1 patch uses the most aggressive setting
> possible: the oldest running multi; the v2 uses the least aggressive
> of the 'safe' and oldest running multi. At firs
gt; WARNING: oldest multixact is far in the past
> HINT: Close open transactions with multixacts soon to avoid
> wraparound problems.
> ERROR: multixact X from before cutoff Y found to be still running
>
> Upon further inspection, I found that this is because the
