Re: Freeze avoidance of very large table.

On Wed, Jul 8, 2015 at 02:31:04PM +0100, Simon Riggs wrote:
> On 7 July 2015 at 18:45, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Wed, Jul 8, 2015 at 12:37 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2015-07-07 16:25:13 +0100, Simon Riggs wrote:
> >> I don't think pg_freespacemap is the right place.
> >
> > I agree that pg_freespacemap sounds like an odd location.
> >
> >> I'd prefer to add that as a single function into core, so we can write
> >> formal tests.
> >
> > With the advent of src/test/modules it's not really a prerequisite for
> > things to be builtin to be testable. I think there's fair arguments for
> > moving stuff like pg_stattuple, pg_freespacemap, pg_buffercache into
> > core at some point, but that's probably a separate discussion.
> >
>
> I understood.
> So I will place bunch of test like src/test/module/visibilitymap_test,
> which contains  some tests regarding this feature,
> and gather them into one patch.
>
>
> Please place it in core. I see value in having a diagnostic function for
> general use on production systems.

Sorry to be coming to this discussion late.

I understand the desire for a diagnostic function in core, but we have
to be consistent. Just because we are adding this function now doesn't
mean we should use different rules from what we did previously for
diagnostic functions. Either their is logic to why this function is
different from the other diagnostic functions in contrib, or we need to
have a separate discussion of whether diagnostic functions belong in
contrib or core.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +