public inbox for [email protected]
help / color / mirror / Atom feed24.1.5.1. Multixacts And Wraparound
7+ messages / 4 participants
[nested] [flat]
* 24.1.5.1. Multixacts And Wraparound
@ 2021-06-17 18:31 PG Doc comments form <[email protected]>
2021-06-18 06:51 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: PG Doc comments form @ 2021-06-17 18:31 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/13/routine-vacuuming.html
Description:
In section "24.1.5.1. Multixacts And Wraparound" of
https://www.postgresql.org/docs/current/routine-vacuuming.html we find the
following sentence towards the end of the section:
"...If the amount of used member storage space exceeds the amount 50% of the
addressable storage space."
I am having trouble parsing "...exceeds the amount 50% of the
addressable..." part.
It seems like the sentence is trying to say "...space exceeds 50% of the
addressable storage space" or maybe even "...space exceeds the amount of the
addressable storage space". Which is which?
Many thanks,
Eric Mutta.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: 24.1.5.1. Multixacts And Wraparound
2021-06-17 18:31 24.1.5.1. Multixacts And Wraparound PG Doc comments form <[email protected]>
@ 2021-06-18 06:51 ` Laurenz Albe <[email protected]>
2021-06-22 02:50 ` Re: 24.1.5.1. Multixacts And Wraparound Bruce Momjian <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Laurenz Albe @ 2021-06-18 06:51 UTC (permalink / raw)
To: [email protected]; [email protected]
On Thu, 2021-06-17 at 18:31 +0000, PG Doc comments form wrote:
> In section "24.1.5.1. Multixacts And Wraparound" of
> https://www.postgresql.org/docs/current/routine-vacuuming.html we find the
> following sentence towards the end of the section:
>
> "...If the amount of used member storage space exceeds the amount 50% of the
> addressable storage space."
>
> I am having trouble parsing "...exceeds the amount 50% of the
> addressable..." part.
>
> It seems like the sentence is trying to say "...space exceeds 50% of the
> addressable storage space" or maybe even "...space exceeds the amount of the
> addressable storage space". Which is which?
+1
I think that the second "the amount" in the sentence should be removed.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: 24.1.5.1. Multixacts And Wraparound
2021-06-17 18:31 24.1.5.1. Multixacts And Wraparound PG Doc comments form <[email protected]>
2021-06-18 06:51 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
@ 2021-06-22 02:50 ` Bruce Momjian <[email protected]>
2021-06-22 06:32 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Bruce Momjian @ 2021-06-22 02:50 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: [email protected]; [email protected]
On Fri, Jun 18, 2021 at 08:51:00AM +0200, Laurenz Albe wrote:
> On Thu, 2021-06-17 at 18:31 +0000, PG Doc comments form wrote:
> > In section "24.1.5.1. Multixacts And Wraparound" of
> > https://www.postgresql.org/docs/current/routine-vacuuming.html we find the
> > following sentence towards the end of the section:
> >
> > "...If the amount of used member storage space exceeds the amount 50% of the
> > addressable storage space."
> >
> > I am having trouble parsing "...exceeds the amount 50% of the
> > addressable..." part.
> >
> > It seems like the sentence is trying to say "...space exceeds 50% of the
> > addressable storage space" or maybe even "...space exceeds the amount of the
> > addressable storage space". Which is which?
>
> +1
>
> I think that the second "the amount" in the sentence should be removed.
I think it is worse than that. Here is the full paragraph:
As a safety device, an aggressive vacuum scan will occur for any table
whose multixact-age is greater than
<xref linkend="guc-autovacuum-multixact-freeze-max-age"/>. Aggressive
vacuum scans will also occur progressively for all tables, starting with
those that have the oldest multixact-age, if the amount of used member
storage space exceeds the amount 50% of the addressable storage space.
Both of these kinds of aggressive scans will occur even if autovacuum is
nominally disabled.
What does "the amount of used member storage space exceeds 50% of the
addressable storage space" mean?
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: 24.1.5.1. Multixacts And Wraparound
2021-06-17 18:31 24.1.5.1. Multixacts And Wraparound PG Doc comments form <[email protected]>
2021-06-18 06:51 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
2021-06-22 02:50 ` Re: 24.1.5.1. Multixacts And Wraparound Bruce Momjian <[email protected]>
@ 2021-06-22 06:32 ` Laurenz Albe <[email protected]>
2021-06-24 19:53 ` Re: 24.1.5.1. Multixacts And Wraparound Bruce Momjian <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Laurenz Albe @ 2021-06-22 06:32 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: [email protected]; [email protected]
On Mon, 2021-06-21 at 22:50 -0400, Bruce Momjian wrote:
> On Fri, Jun 18, 2021 at 08:51:00AM +0200, Laurenz Albe wrote:
> > On Thu, 2021-06-17 at 18:31 +0000, PG Doc comments form wrote:
> > > In section "24.1.5.1. Multixacts And Wraparound" of
> > > https://www.postgresql.org/docs/current/routine-vacuuming.html we find the
> > > following sentence towards the end of the section:
> > >
> > > "...If the amount of used member storage space exceeds the amount 50% of the
> > > addressable storage space."
> > >
> > > I am having trouble parsing "...exceeds the amount 50% of the
> > > addressable..." part.
> >
> > I think that the second "the amount" in the sentence should be removed.
>
> I think it is worse than that. Here is the full paragraph:
>
> As a safety device, an aggressive vacuum scan will occur for any table
> whose multixact-age is greater than
> <xref linkend="guc-autovacuum-multixact-freeze-max-age"/>. Aggressive
> vacuum scans will also occur progressively for all tables, starting with
> those that have the oldest multixact-age, if the amount of used member
> storage space exceeds the amount 50% of the addressable storage space.
> Both of these kinds of aggressive scans will occur even if autovacuum is
> nominally disabled.
>
> What does "the amount of used member storage space exceeds 50% of the
> addressable storage space" mean?
You are right. See MultiXactMemberFreezeThreshold for the whole story.
What about:
As a safety device, an aggressive vacuum scan will occur for any table
whose multixact-age (see <xref linkend="vacuum-for-multixact-wraparound"/>)
is greater than <xref linkend="guc-autovacuum-multixact-freeze-max-age"/>.
Also, if the storage occupied by multixacts exceeds 2GB, aggressive vacuum
scans will occur more often for all tables, starting with those that have
the oldest multixact-age.
Both of these kinds ...
I hope I read the source right concerning the 2GB.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: 24.1.5.1. Multixacts And Wraparound
2021-06-17 18:31 24.1.5.1. Multixacts And Wraparound PG Doc comments form <[email protected]>
2021-06-18 06:51 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
2021-06-22 02:50 ` Re: 24.1.5.1. Multixacts And Wraparound Bruce Momjian <[email protected]>
2021-06-22 06:32 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
@ 2021-06-24 19:53 ` Bruce Momjian <[email protected]>
2021-06-24 20:06 ` Re: 24.1.5.1. Multixacts And Wraparound Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Bruce Momjian @ 2021-06-24 19:53 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: [email protected]; [email protected]
On Tue, Jun 22, 2021 at 08:32:18AM +0200, Laurenz Albe wrote:
> > What does "the amount of used member storage space exceeds 50% of the
> > addressable storage space" mean?
>
> You are right. See MultiXactMemberFreezeThreshold for the whole story.
>
> What about:
>
> As a safety device, an aggressive vacuum scan will occur for any table
> whose multixact-age (see <xref linkend="vacuum-for-multixact-wraparound"/>)
> is greater than <xref linkend="guc-autovacuum-multixact-freeze-max-age"/>.
> Also, if the storage occupied by multixacts exceeds 2GB, aggressive vacuum
> scans will occur more often for all tables, starting with those that have
> the oldest multixact-age.
> Both of these kinds ...
Yes, very good. There were three problems with the original paragraph:
* Had duplicate words
* Had awkward phrasing
* Used undefined terms
Your version fixes all three of those. Patch attached.
> I hope I read the source right concerning the 2GB.
I can confirm the 2GB. do_vacuum() calls
MultiXactMemberFreezeThreshold() to set its
effective_multixact_freeze_max_age. MultiXactMemberFreezeThreshold()
compares the number of members to 2^32 (0xFFFFFFFF) / 2 or 2GB:
#define MaxMultiXactOffset ((MultiXactOffset) 0xFFFFFFFF)
#define MULTIXACT_MEMBER_SAFE_THRESHOLD (MaxMultiXactOffset / 2)
/* If member space utilization is low, no special action is required. */
if (members <= MULTIXACT_MEMBER_SAFE_THRESHOLD)
return autovacuum_multixact_freeze_max_age;
If that test fails, autovacuum_multixact_freeze_max_age is set much more
aggressively.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
Attachments:
[text/x-diff] mxact.diff (1.4K, 2-mxact.diff)
download | inline diff:
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 4b535809b6..dd0eed193e 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -697,14 +697,14 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
</para>
<para>
- As a safety device, an aggressive vacuum scan will occur for any table
- whose multixact-age is greater than
- <xref linkend="guc-autovacuum-multixact-freeze-max-age"/>. Aggressive
- vacuum scans will also occur progressively for all tables, starting with
- those that have the oldest multixact-age, if the amount of used member
- storage space exceeds the amount 50% of the addressable storage space.
- Both of these kinds of aggressive scans will occur even if autovacuum is
- nominally disabled.
+ As a safety device, an aggressive vacuum scan will
+ occur for any table whose multixact-age (see <xref
+ linkend="vacuum-for-multixact-wraparound"/>) is greater than <xref
+ linkend="guc-autovacuum-multixact-freeze-max-age"/>. Also, if the
+ storage occupied by multixacts exceeds 2GB, aggressive vacuum scans
+ will occur more often for all tables, starting with those that have
+ the oldest multixact-age. Both of these kinds of aggressive scans
+ will occur even if autovacuum is nominally disabled.
</para>
</sect3>
</sect2>
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: 24.1.5.1. Multixacts And Wraparound
2021-06-17 18:31 24.1.5.1. Multixacts And Wraparound PG Doc comments form <[email protected]>
2021-06-18 06:51 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
2021-06-22 02:50 ` Re: 24.1.5.1. Multixacts And Wraparound Bruce Momjian <[email protected]>
2021-06-22 06:32 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
2021-06-24 19:53 ` Re: 24.1.5.1. Multixacts And Wraparound Bruce Momjian <[email protected]>
@ 2021-06-24 20:06 ` Alvaro Herrera <[email protected]>
2021-07-02 22:01 ` Re: 24.1.5.1. Multixacts And Wraparound Bruce Momjian <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Alvaro Herrera @ 2021-06-24 20:06 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]; [email protected]
On 2021-Jun-24, Bruce Momjian wrote:
> + As a safety device, an aggressive vacuum scan will
> + occur for any table whose multixact-age (see <xref
> + linkend="vacuum-for-multixact-wraparound"/>) is greater than <xref
> + linkend="guc-autovacuum-multixact-freeze-max-age"/>. Also, if the
> + storage occupied by multixacts exceeds 2GB, aggressive vacuum scans
> + will occur more often for all tables, starting with those that have
> + the oldest multixact-age. Both of these kinds of aggressive scans
> + will occur even if autovacuum is nominally disabled.
This looks good, thanks.
I think "the space occupied by multixacts" is a bit ambiguous -- it is
talking about pg_multixact/members only, but you could interpret that it
talks about both that and pg_multixact/offsets. I'm not sure we need to
be 100% precise about that, so perhaps what you have is sufficient. But
if we do want to be precise, then maybe " ... if the storage occupied by
multixact members (<literal>pg_multixact/members/</literal>) exceeds ..."
covers it.
(At least, that's how I remember this. I don't think things have
changed much since 53bb309d2d5a ...)
--
Álvaro Herrera Valdivia, Chile
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: 24.1.5.1. Multixacts And Wraparound
2021-06-17 18:31 24.1.5.1. Multixacts And Wraparound PG Doc comments form <[email protected]>
2021-06-18 06:51 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
2021-06-22 02:50 ` Re: 24.1.5.1. Multixacts And Wraparound Bruce Momjian <[email protected]>
2021-06-22 06:32 ` Re: 24.1.5.1. Multixacts And Wraparound Laurenz Albe <[email protected]>
2021-06-24 19:53 ` Re: 24.1.5.1. Multixacts And Wraparound Bruce Momjian <[email protected]>
2021-06-24 20:06 ` Re: 24.1.5.1. Multixacts And Wraparound Alvaro Herrera <[email protected]>
@ 2021-07-02 22:01 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Bruce Momjian @ 2021-07-02 22:01 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Laurenz Albe <[email protected]>; [email protected]; [email protected]
On Thu, Jun 24, 2021 at 04:06:38PM -0400, Álvaro Herrera wrote:
> On 2021-Jun-24, Bruce Momjian wrote:
>
> > + As a safety device, an aggressive vacuum scan will
> > + occur for any table whose multixact-age (see <xref
> > + linkend="vacuum-for-multixact-wraparound"/>) is greater than <xref
> > + linkend="guc-autovacuum-multixact-freeze-max-age"/>. Also, if the
> > + storage occupied by multixacts exceeds 2GB, aggressive vacuum scans
> > + will occur more often for all tables, starting with those that have
> > + the oldest multixact-age. Both of these kinds of aggressive scans
> > + will occur even if autovacuum is nominally disabled.
>
> This looks good, thanks.
>
> I think "the space occupied by multixacts" is a bit ambiguous -- it is
> talking about pg_multixact/members only, but you could interpret that it
> talks about both that and pg_multixact/offsets. I'm not sure we need to
> be 100% precise about that, so perhaps what you have is sufficient. But
> if we do want to be precise, then maybe " ... if the storage occupied by
> multixact members (<literal>pg_multixact/members/</literal>) exceeds ..."
> covers it.
>
> (At least, that's how I remember this. I don't think things have
> changed much since 53bb309d2d5a ...)
OK, I got "members" into the doc section and applied it to master and PG
14.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2021-07-02 22:01 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-06-17 18:31 24.1.5.1. Multixacts And Wraparound PG Doc comments form <[email protected]>
2021-06-18 06:51 ` Laurenz Albe <[email protected]>
2021-06-22 02:50 ` Bruce Momjian <[email protected]>
2021-06-22 06:32 ` Laurenz Albe <[email protected]>
2021-06-24 19:53 ` Bruce Momjian <[email protected]>
2021-06-24 20:06 ` Alvaro Herrera <[email protected]>
2021-07-02 22:01 ` Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox