On Wed, Feb 16, 2022 at 2:29 AM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Mon, Feb 14, 2022 at 10:04 PM John Naylor
> <john.naylor@enterprisedb.com> 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/
