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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Дата
Msg-id 25004.1029245060@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke  (Thomas Lockhart <lockhart@fourpalms.org>)
Ответы Re: [COMMITTERS] pgsql-server/src
Список 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 по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: [GENERAL] Linux Largefile Support In Postgresql RPMS
Следующее
От: "Zeugswetter Andreas SB SD"
Дата:
Сообщение: Re: [GENERAL] Linux Largefile Support In Postgresql RPMS