On Thu, Apr 16, 2020 at 5:20 PM Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Apr 16, 2020 at 4:43 AM Hamid Akhtar <hamid.akh...@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. > > -- > 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.akh...@highgo.ca SKYPE: engineeredvirus
