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

From Masahiko Sawada
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CAD21AoCY2aGqQ=0UA-vk7y9RO0oyH=N=0yiSW4PnPPUP7jZpYQ@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Freeze avoidance of very large table.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Aug 10, 2015 at 11:05 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Aug 10, 2015 at 12:39 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Aug 6, 2015 at 11:33 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>>> They also provide a level of control over what is and isn't installed in a
>>> cluster. Personally, I'd prefer that most users not even be aware of the
>>> existence of things like pageinspect.
>>
>> +1.
>>
>> [...]
>>
>> Extensions are a useful packaging mechanism for functionality that is
>> useful but not required, and debugging facilities are definitely very
>> useful but should not be required.
>
> +1.

Sorry to be come discussion late.

I have encountered the much cases where pg_stat_statement,
pgstattuples are required in production, so I basically agree with
moving such extension into core.
But IMO, the diagnostic tools for visibility map, heap (pageinspect)
and so on, are a kind of debugging tool.

Attached latest v11 patches, which is separated into 2 patches: frozen
bit patch and diagnostic function patch.
Moving diagnostic function into core is still under the discussion,
but this patch puts such function into core because the diagnostic
function for visibility map needs to be in core to execute regression
test at least.

Regards,

--
Masahiko Sawada

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Declarative partitioning
Next
From: Peter Eisentraut
Date:
Subject: allowing wal_level change at run time