Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Date
Msg-id 25004.1029245060@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke  (Thomas Lockhart <lockhart@fourpalms.org>)
Responses Re: [COMMITTERS] pgsql-server/src  (Oliver Elphick <olly@lfix.co.uk>)
List pgsql-hackers
Thomas Lockhart <lockhart@fourpalms.org> writes:
> In the spirit of gratutious overstatement, I'll point out again:
> symlinks are evil.

Please justify that claim.  They work really nicely in my experience...
and I don't know of any modern Unix system that doesn't rely on them
*heavily*.

Possibly more to the point, I can assert "environment variables are
evil" with at least as much foundation.  We have seen many many reports
of trouble from people who were bit by environment-variable problems
with Postgres.  Do I need to trawl the archives for examples?

However, as I just commented to Marc the real issue in my mind is that
the xlog needs to be solidly tied to the data directory, because we
can't risk starting a postmaster with the wrong combination.  I do not
think that external specification of the xlog as a separate env-var or
postmaster command-line arg gives the appropriate amount of safety.
But there's more than one way to record the xlog location in the data
directory.  If you don't like a symlink, what of putting it in
postgresql.conf as a postmaster-start-time-only config option?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: [GENERAL] Linux Largefile Support In Postgresql RPMS
Next
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: [GENERAL] Linux Largefile Support In Postgresql RPMS