Re: truncating pg_multixact/members

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: truncating pg_multixact/members
Date: 2014-01-06 19:13:21
Message-ID: CA+TgmobeN-x03f_4cBT_H9fFPhCJLZ1WkqG=Njsm_zgt2pVP4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 4, 2014 at 12:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> As far as back-patching the GUCs, my thought would be to back-patch
>> them but mark them GUC_NOT_IN_SAMPLE in 9.3, so we don't have to touch
>> the default postgresql.conf.
>
> That seems bizarre and pointless.
>
> Keep in mind that 9.3 is still wet behind the ears and many many people
> haven't adopted it yet. If we do what you're suggesting then we're
> creating a completely useless inconsistency that will nonetheless affect
> all those future adopters ... while accomplishing nothing much for those
> who have already installed 9.3. The latter are not going to have these
> GUCs in their existing postgresql.conf, true, but there's nothing we can
> do about that. (Hint: GUC_NOT_IN_SAMPLE doesn't actually *do* anything,
> other than prevent the variable from being shown by SHOW ALL, which is not
> exactly helpful here.)

Well, I guess what I'm really wondering is whether we should refrain
from patching postgresql.conf.sample in 9.3, even if we add the GUC,
just because people may have existing configuration files that they've
already modified, and it could perhaps create confusion.

--
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 2014-01-06 19:16:25 Re: [PATCH] Store Extension Options
Previous Message Mark Dilger 2014-01-06 19:10:19 Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier