On Fri, Apr 17, 2020 at 5:40 AM Michael Paquier <michael@paquier.xyz> wrote:
On Thu, Apr 16, 2020 at 03:11:51PM -0400, Tom Lane wrote: > Even if I liked the core idea, loading the functionality onto VACUUM seems > like a fairly horrid design choice. It's quite unrelated to what that > command does. In the autovac code path, it's going to lead to multiple > autovac workers all complaining simultaneously about the same problem. > But having manual vacuums complain about issues unrelated to the task at > hand is also a seriously poor bit of UX design. Moreover, that won't do > all that much to surface problems, since most(?) installations never run > manual vacuums; or if they do, the "manual" runs are really done by a cron > job or the like, which is not going to notice the warnings. So you still > need a log-scraping tool.
+1.
> If we were going to go down the path of periodically logging warnings > about old prepared transactions, some single-instance background task > like the checkpointer would be a better place to do the work in. But > I'm not really recommending that, because I agree with Robert that > we just plain don't want this functionality.
I am not sure that the checkpointer is a good place to do that either, joining back with your argument in the first paragraph of this email related to vacuum. One potential approach would be a contrib module that works as a background worker? However, I would think that finding a minimum set of requirements that we think are generic enough for most users would be something hard to draft a list of. If we had a small, minimal contrib/ module in core that people could easily extend for their own needs and that we would intentionally keep as minimal, in the same spirit as say passwordcheck, perhaps.. -- Michael
