On Mon, Jul 13, 2020 at 6:15 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Yeah, I don't care for that either. That's a pretty huge violation of our > normal back-patching rules, and I'm not convinced that it's justified.
I think that our normal back-patching rules are based primarily on the risk of breaking things, and a new contrib module carries a pretty negligible risk of breaking anything that works today. I wouldn't propose to back-patch something on those grounds just as a way of delivering a new feature more quickly, but that's not the intention here. At least in my experience, un-VACUUM-able tables have gotten several orders of magnitude more common since Andres put those changes in. As far as I can recall, EDB has not had this many instances of different customers reporting the same problem since the 9.3-era multixact issues. So far, this does not rise to that level, but it is by no means a negligible issue, either. I believe it deserves to be taken quite seriously, especially because the existing options for helping customers with this kind of problem are so limited. Now, if this goes into v14, we can certainly stick it up on github, or put it out there in some other way for users to download, self-compile, and install, but that seems noticeably less convenient for people who need it, and I'm not clear what the benefit to the project is. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
