Re: Bogus path in postmaster.opts

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bogus path in postmaster.opts
Date: 2006-01-19 18:06:30
Message-ID: 200601191906.31373.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> find_my_exec is not misbehaving: it's designed to expand symlinks,
> and would in fact be pretty useless if it did not.

I don't want to contest that in certain cases this is required but I can
easily come up with scenarios (which perhaps no PostgreSQL user has
encountered yet) where the currently behavior is broken. One example
is a GNU Stow like installation management where each package is
installed in a private directory and the canonical locations
in /usr/local are symlinks. (It's altogether strange that this would
distinguish between symbolic and hard links anyway, except that of
course it cannot actually "resolve" hard links, since many installation
schemes that one needs to cope with work the same with hard and soft
links.)

> There is another possible answer, and it's something I've been
> meaning to bring up for awhile. Is there a good reason why
> postmaster is a symlink to postgres, rather than a hard link?

I don't know of one. Something I have thought of during the recent
options reorganization is that we could do away with the
postmaster/postgres dichotomy altogether. Just call the thing
postmaster and give it a --single-user-mode option.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2006-01-19 18:09:26 Re: Surrogate keys (Was: enums)
Previous Message Josh Berkus 2006-01-19 18:01:57 Re: FW: Surrogate keys (Was: enums)