> Robert Treat <xzilla@users.sourceforge.net> writes:
>> On Thu, 2004-04-08 at 09:49, pgsql@mohawksoft.com wrote:
>>> (2) I would bet that *most* deployments of PostgreSQL only use one
>>> database environment per server, so I'm not even sure that it would be
>>> an
>>> issue for the majority of current or prospective users.
>
>> except that when doing major version upgrades, i find it far better
>> practice to install multiple versions on the machine whenever possible,
>> even if you only intend to run a single version.
>
> In any case, you will never get such a proposal past the core
> developers, because we all run multiple PG installs per machine.
> My primary development machine currently has six postmasters alive
> on it (7.0, 7.1, ..., 7.4 + CVS tip); my alternate machine has five
> installations on it, though not all are alive since I've not had reason
> to restart them all since last reboot; even the laptop I'm physically
> typing on right now has more than one Postgres installation on it.
> And practically any time someone allows me access to a machine of
> theirs to check out some kind of portability issue, I'll build a test
> installation in my guest-account home directory, rather than muck with
> their live server.
>
> So, don't bother proposing anything that makes it even slightly harder
> to run multiple servers per machine. It will not happen. End of
> discussion.
>
The problem with this conversation is that you assume the functionality
desired would affect your methodology in any way.
All I am asking for, and this is what my patch did, was add a few entries
to postgresql.conf. "data_dir, hba_conf, and ident_conf. A later version
of the patch added "include" and "runtime_pidfile."
These features allow a postgreSQL system to be fully configurable via a
postgresql.conf file. It may, in fact, make it easier to have multiple
installs.