From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Kellerer <shammat(at)gmx(dot)net> |
Subject: | Re: Do we need to handle orphaned prepared transactions in the server? |
Date: | 2020-04-17 00:40:12 |
Message-ID: | 20200417004012.GF81957@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-04-17 00:54:20 | Re: sqlsmith crash incremental sort |
Previous Message | Justin Pryzby | 2020-04-17 00:27:27 | Re: Problem with logical replication (crash with REPLICA IDENTITY FULL and cascading replication) |