Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CANP8+jKLc9Fo_+v6v2sQiU74hhrvGrukq-hoaVSX+-y+AzwawA@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Responses Re: Freeze avoidance of very large table.
Re: Freeze avoidance of very large table.
Re: Freeze avoidance of very large table.
List pgsql-hackers
On 7 July 2015 at 18:45, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
On Wed, Jul 8, 2015 at 12:37 AM, Andres Freund <andres@anarazel.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.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Zhaomo Yang
Date:
Subject: Re: Implementation of global temporary tables?
Next
From: Tom Lane
Date:
Subject: Re: configure can't detect proper pthread flags