| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Kellerer <shammat(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Do we need to handle orphaned prepared transactions in the server? |
| Date: | 2020-04-16 12:20:34 |
| Message-ID: | CA+TgmoZ5Dh6AkO65jhVP8HBLtOZ0c_EeHVr_f0gbbwmnJ9b9kw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 16, 2020 at 4:43 AM Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com> wrote:
> My real question is whether vacuum should be preemptively complaining about prepared transactions or stale replication slots rather than waiting for transaction id to exceed the safe limit. I presume by the time safe limit is exceeded, vacuum's work would already have been significantly impacted.
Yeah, for my part, I agree that letting things go until the point
where VACUUM starts to complain is usually bad. Generally, you want to
know a lot sooner. That being said, I think the solution to that is to
run a monitoring tool, not to overload the autovacuum worker with
additional duties.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2020-04-16 12:21:51 | Re: sqlsmith crash incremental sort |
| Previous Message | Daniel Gustafsson | 2020-04-16 12:17:33 | Making openssl_tls_init_hook OpenSSL specific |