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

From Robert Haas
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CA+TgmobSOmeZKAbUuGgN7d30hJ2XwBSKVoWpDuDQD0nEOR+XVg@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Freeze avoidance of very large table.
List pgsql-hackers
On Tue, Aug 18, 2015 at 7:27 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> 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.

Just because something might be required in production isn't a
sufficient reason to put it in core.  Debugging tools, or anything
else, can be required in production, too.

> 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.

As has been discussed recently, there are other ways to handle that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: allowing wal_level change at run time
Next
From: Robert Haas
Date:
Subject: Re: allowing wal_level change at run time