public inbox for [email protected]  
help / color / mirror / Atom feed
From: Masahiko Sawada <[email protected]>
To: Peter Geoghegan <[email protected]>
Cc: John Naylor <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: do only critical work during single-user vacuum?
Date: Thu, 17 Feb 2022 01:47:31 +0900
Message-ID: <CAD21AoCAKf+yq8pHLpmyxxS=A5zNFUvxTeergLOhobjYaJbF+Q@mail.gmail.com> (raw)
In-Reply-To: <CAH2-WzkpZcat1YmEVAKpcMBaWRXUd2vGVKHtrBjzBGDL=j6mbA@mail.gmail.com>
References: <CAFBsxsFL5LoWanSLDjt_SjS9=FU_9XWi22iHMexRS2SubkX-Vw@mail.gmail.com>
	<CAH2-Wz=Z5Jjd1y8kCfXd6e-GSvKiL8XEmxoJJFNHcekM4aw-Vg@mail.gmail.com>
	<CAH2-Wzn3pE8rNzBxh-Qpmq=zxFWFpoC7LWLbyDg_1XZ3wJOtUA@mail.gmail.com>
	<CAFBsxsG-VDhXYa25uERfDGD4dO_AZ3d+Dv2NF+DJBADZiXejpw@mail.gmail.com>
	<CAH2-Wznop1jM3j6E1xTcG--kFQ1hW5cMmM8B1965Mz+uUg6HSg@mail.gmail.com>
	<[email protected]>
	<CA+TgmoYPfofQmRtUan=A3aWE9wFsJaOFr+W_ys2pPkNPr-2FZw@mail.gmail.com>
	<CAFBsxsGaZZTfLgd+H+VG6mxv5KfDxYf43tqOr_JqdwstCy=pLA@mail.gmail.com>
	<CA+TgmoY3m3RimCHifQnxU3YDVV7oYRbRUX4GZ4FuYkhnhe0giA@mail.gmail.com>
	<[email protected]>
	<CAFBsxsHp3brGqWu5vU_6d5wfOU5i40c8u3Hg=3TtN4qZwmAecw@mail.gmail.com>
	<CAH2-WzkEStBgnk0buJYAKw5jpRYUE+-tuLYn5U+vDyhXNfu+DQ@mail.gmail.com>
	<CAFBsxsFiMPxQ-dHZ8tOgktn=+ffeJT3+GinZ4zdOGbmAnCYadA@mail.gmail.com>
	<CAH2-WzkpZcat1YmEVAKpcMBaWRXUd2vGVKHtrBjzBGDL=j6mbA@mail.gmail.com>

On Wed, Feb 16, 2022 at 2:29 AM Peter Geoghegan <[email protected]> wrote:
>
> On Mon, Feb 14, 2022 at 10:04 PM John Naylor
> <[email protected]> wrote:
> > Well, the point of inventing this new vacuum mode was because I
> > thought that upon reaching xidStopLimit, we couldn't issue commands,
> > period, under the postmaster. If it was easier to get a test instance
> > to xidStopLimit, I certainly would have discovered this sooner.
>
> I did notice from my own testing of the failsafe (by artificially
> inducing wraparound failure using an XID burning C function) that
> autovacuum seemed to totally correct the problem, even when the system
> had already crossed xidStopLimit - it came back on its own. I wasn't
> completely sure of how robust this effect was, though.

FYI, I've tested the situation that I assumed autovacuum can not
correct the problem; when the system had already crossed xidStopLimit,
it keeps failing to vacuum on tables that appear in the front of the
list and have sufficient garbage to trigger the truncation but are not
older than the failsafe limit. But contrary to my assumption, it did
correct the problem since autovacuum continues to the next table in
the list even after an error. This probably means that autovacuum
eventually succeeds to process all tables that trigger the failsafe
mode, ensuring advancing datfrozenxid, which is great.

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/






view thread (14+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: do only critical work during single-user vacuum?
  In-Reply-To: <CAD21AoCAKf+yq8pHLpmyxxS=A5zNFUvxTeergLOhobjYaJbF+Q@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox