On Fri, Mar 27, 2020 at 12:12 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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.
Sounds great. I will email you directly with a link!
> > 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).
This is encouraging. As I mentioned, we have a workaround in place for
the moment, but don't hesitate if you need anything else from me.
Thanks for jumping in on the thread, it was nice validation to know
that I wasn't the only one seeing the issue!
> --
> Michael