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
Attachment:
signature.asc
Description: PGP signature
