Обсуждение: Bogus path in postmaster.opts

Since 8.0, postmaster.opts has been containing .../bin/postgres even though 
the postmaster was started.  This was evidently broken by some 
Windows-related reshuffling.

Earlier, CreateOptsFile was called with argv, now it's passed the result of 
find_my_exec instead.  I'm not sure whether that change was wrong to begin 
with or whether find_my_exec is mishaving (it should return something 
containing "postmaster", no?).

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

Peter Eisentraut <peter_e@gmx.net> writes:
> Earlier, CreateOptsFile was called with argv, now it's passed the result of 
> find_my_exec instead.  I'm not sure whether that change was wrong to begin 
> with or whether find_my_exec is mishaving (it should return something 
> containing "postmaster", no?).

find_my_exec is not misbehaving: it's designed to expand symlinks, and
would in fact be pretty useless if it did not.  We could go back to
storing the raw value of argv[0] in the opts file, but I rather like
having the full path in there.

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?  Surely the symlink way
is not any more efficient.  The thing that ticks me off about this
is that it confuses gdb: if you say "gdb postmaster" and then "run",
what gets passed as argv[0] is "postgres", thus breaking your test.
So I not infrequently find myself manually replacing the symlink with
a hard link in order to be able to test.  If it'd result in nicer
output in the opts file too, then all the more reason to change.
        regards, tom lane

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/

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> 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.

No strong objection here, though combining the two manpages is likely
to be a mess :-(
        regards, tom lane