On 2020/07/14 9:41, Robert Haas wrote:
> On Mon, Jul 13, 2020 at 6:15 PM Tom Lane <tgl@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.
But updating this tool can fit to the release schedule and
policy of PostgreSQL?
While investigating the problem by using this tool, we may want to
add new feature into the tool because it's necessary for the investigation.
But users would need to wait for next minor version release, to use this
new feature.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
