Hi, Peter!
Sorry! For a some time i forgot about this thread and forgot to
thank you for your answer.
Thereby now its clear for me that this patch allows the autovacuum to win some
time between OldestXmin and nextXID that could not be used before.
I think, it maybe especially useful for high-loa
On Mon, Oct 24, 2022 at 7:56 AM Peter Geoghegan wrote:
> I don't understand what you mean. FreezeLimit *isn't* always exactly
> 50 million XIDs before OldestXmin -- not anymore. In fact that's the
> main benefit of this work (commit c3ffa731). That detail has changed
> (and changed for the better)
On Mon, Oct 24, 2022 at 1:18 AM Anton A. Melnikov wrote:
> > Also, the proposed new WARNING is only seen when we're
> > bound to also see the existing OldestXmin WARNING already. Why have 2
> > WARNINGs about exactly the same problem?>
>
> I didn't understand this moment.
>
> If the FreezeLimit is
Hello!
On 18.10.2022 20:56, Peter Geoghegan wrote:
The term "removable cutoff" is how VACUUM VERBOSE reports OldestXmin.
I think that it's good to use the same terminology here.
Thanks for the explanation! Firstly exactly this term confused me.
Sure, the same terminology makes all easier to
On Tue, Oct 18, 2022 at 3:43 AM Anton A. Melnikov wrote:
> It's interesting that prior to this commit, checks were made for freeze
> limits, but the error messages were talking about oldestXmin and oldestMxact.
The problem really is that oldestXmin and oldestMxact are held back,
though. While th
Hello!
On 31.08.2022 21:38, Peter Geoghegan wrote:
On Tue, Aug 30, 2022 at 8:56 PM Nathan Bossart wrote:
LGTM
Pushed, thanks.
In this commit
https://github.com/postgres/postgres/commit/c3ffa731a5f99c4361203015ce2219d209fea94c
there are checks if oldestXmin and oldestMxact havn't become t
On Tue, Aug 30, 2022 at 8:56 PM Nathan Bossart wrote:
> LGTM
Pushed, thanks.
--
Peter Geoghegan
On Tue, Aug 30, 2022 at 05:24:17PM -0700, Peter Geoghegan wrote:
> Attached is v2, which cleans up the structure of
> vacuum_set_xid_limits() a bit more. The overall idea was to improve
> the overall flow/readability of the function by moving the WARNINGs
> into their own "code stanza", just after
On Mon, Aug 29, 2022 at 3:40 PM Nathan Bossart wrote:
> Agreed.
Attached is v2, which cleans up the structure of
vacuum_set_xid_limits() a bit more. The overall idea was to improve
the overall flow/readability of the function by moving the WARNINGs
into their own "code stanza", just after the log
On Mon, Aug 29, 2022 at 2:20 AM Matthias van de Meent
wrote:
> Apart from the message that this behaviour is changing, I'd prefer
> some more description in the commit message as to why this needs
> changing.
I usually only write a full commit message before posting a patch when
it's a full patch
On Mon, Aug 29, 2022 at 10:25:50AM -0700, Peter Geoghegan wrote:
> On Sun, Aug 28, 2022 at 4:14 PM Nathan Bossart
> wrote:
>> The idea seems sound to me, and IMO your patch simplifies things nicely,
>> which might be reason enough to proceed with it.
>
> It is primarily a case of making things s
On Sun, Aug 28, 2022 at 4:14 PM Nathan Bossart wrote:
> The idea seems sound to me, and IMO your patch simplifies things nicely,
> which might be reason enough to proceed with it.
It is primarily a case of making things simpler. Why would it ever
make sense to interpret age differently in the pre
On Sun, 28 Aug 2022 at 20:38, Peter Geoghegan wrote:
>
> On Tue, Aug 2, 2022 at 4:12 PM Peter Geoghegan wrote:
> > That is, we only need to make sure that the "multiXactCutoff must
> > always be <= oldestMxact" invariant holds once, by checking for it
> > directly. The same thing happens with Old
On Sun, Aug 28, 2022 at 11:38:09AM -0700, Peter Geoghegan wrote:
> On Tue, Aug 2, 2022 at 4:12 PM Peter Geoghegan wrote:
>> That is, we only need to make sure that the "multiXactCutoff must
>> always be <= oldestMxact" invariant holds once, by checking for it
>> directly. The same thing happens wi
On Tue, Aug 2, 2022 at 4:12 PM Peter Geoghegan wrote:
> That is, we only need to make sure that the "multiXactCutoff must
> always be <= oldestMxact" invariant holds once, by checking for it
> directly. The same thing happens with OldestXmin/FreezeLimit. That
> seems like a simpler foundation. It'
The effective_multixact_freeze_max_age mechanism added by commit
53bb309d2d forces aggressive VACUUMs to take place earlier, as
protection against wraparound of the MultiXact member space SLRU.
There was also a follow-up bugfix several years later -- commit
6bda2af039 -- which made sure that the MX
16 matches
Mail list logo
