Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade - add config directory setting

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Steve Crawford <scrawford(at)pinpointresearch(dot)com>, "Mr(dot) Aaron W(dot) Swenson" <titanofold(at)gentoo(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_upgrade - add config directory setting
Date: 2011-09-29 21:55:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > pg_upgrade is not about to start reading through postgresql.conf looking
> > for a definition for data_directory --- there are too many cases where
> > this could go wrong.  It would need a full postgresql.conf parser.
> Yeah.  I think the only sensible way to do this would be to provide an
> operating mode for the postgres executable that would just parse the
> config file and spit out requested values.  We've had requests for that
> type of functionality before, IIRC.  The --describe-config option does
> something related, but not what's needed here.

That would certainly solve the problem, though it would have to be
backpatched all the way back to 8.4, and it would require pg_upgrade
users to be on newer minor versions of Postgres.  We could minimize that
by using this feature only if postgresql.conf exists in the specified
data directory but PG_VERSION does not.

Adding this features is similar to this TODO item:

	Allow configuration files to be independently validated 

This still seems like a lot to backpatch.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-09-29 22:18:27
Subject: Re: pg_upgrade - add config directory setting
Previous:From: Alexander KorotkovDate: 2011-09-29 21:29:06
Subject: Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group