Re: Freeze avoidance of very large table.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Freeze avoidance of very large table.
Date: 2015-08-18 16:28:58
Message-ID: CA+TgmobSOmeZKAbUuGgN7d30hJ2XwBSKVoWpDuDQD0nEOR+XVg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 18, 2015 at 7:27 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-08-18 16:35:22 Re: allowing wal_level change at run time
Previous Message Peter Eisentraut 2015-08-18 16:27:41 Re: allowing wal_level change at run time