On Thu, Mar 26, 2020 at 09:46:47AM -0500, Justin King wrote:
> Nope, it was just these tables that were looping over and over while
> nothing else was getting autovac'd. I'm happy to share the full log
> if you'd like.
Thanks, that could help. If that's very large, it could be a problem
to send that to the lists, but you could send me directly a link to
it and I'll try to extract more information for the lists. While
testing for reproducing the issue, I have noticed that basically one
set of catalog tables happened to see this "skipping redundant" log.
And I am wondering if we have a match with the set of catalog tables
looping.
> I did have to remove it from this state, but I can undo my workaround
> and, undoubtedly, it'll end up back there. Let me know if there's
> something specific you'd like me to provide when it happens!
For now I think it's fine. Note that Julien and I have an environment
where the issue can be reproduced easily (it takes roughly 12 hours
until the wraparound cutoffs are reached with the benchmark and
settings used), and we are checking things using a patched instance
with 2aa6e33 reverted. I think that we are accumulating enough
evidence that this change was not a good idea anyway thanks to the
information you sent, so likely we'll finish first by a revert of
2aa6e33 from the master and REL_12_STABLE branches, before looking at
the issues with the catalogs for those anti-wraparound and
non-aggressive jobs (this looks like a relcache issue with the so-said
catalogs).
--
Michael