Re: Do we need to handle orphaned prepared transactions in the server?
| От | Hamid Akhtar |
|---|---|
| Тема | Re: Do we need to handle orphaned prepared transactions in the server? |
| Дата | |
| Msg-id | CANugjhs0s47nc8_z-W5C0Wts6gNpf5Z0R0Na4TMt1Xa-wahaKA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Do we need to handle orphaned prepared transactions in the server? (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Do we need to handle orphaned prepared transactions in the server?
|
| Список | pgsql-hackers |
On Thu, Apr 16, 2020 at 5:20 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Apr 16, 2020 at 4:43 AM Hamid Akhtar <hamid.akhtar@gmail.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.
So is the concern performance overhead rather than the need for such a feature?
Any server running with prepared transactions enabled, more likely than not, requires a monitoring tool for tracking orphaned prepared transactions. For such environments, surely the overhead created by such a feature implemented in the server will create a lower overhead than their monitoring tool.
Any server running with prepared transactions enabled, more likely than not, requires a monitoring tool for tracking orphaned prepared transactions. For such environments, surely the overhead created by such a feature implemented in the server will create a lower overhead than their monitoring tool.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
ADDR: 10318 WHALLEY BLVD, Surrey, BC
CELL：+923335449950 EMAIL: mailto:hamid.akhtar@highgo.ca
URL : www.highgo.ca
ADDR: 10318 WHALLEY BLVD, Surrey, BC
CELL：+923335449950 EMAIL: mailto:hamid.akhtar@highgo.ca
SKYPE: engineeredvirus
В списке pgsql-hackers по дате отправления: