Re: WAL file location

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: WAL file location
Дата
Msg-id 3D477A37.1E507C2B@fourpalms.org
обсуждение исходный текст
Ответ на Re: WAL file location  (Curt Sampson <cjs@cynic.net>)
Ответы Re: WAL file location  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Whether you think that there is a potentially-exploitable security hole
> here is not really the issue.  The point is that two different arguments
> have been advanced against using environment variables for configuration
> (if you weren't counting, (1) possible security issues now or in the
> future and (2) lack of consistency between manual and boot-script
> startup), while zero (as in 0, nil, nada) arguments have been advanced
> in favor of using environment variables instead of configuration files.

I have been counting, in both English and Spanish. Other folks can count
too, and no point in just being pissy about it. You haven't been
listening ;)

I've discussed these issues in the past, and we get stuck in the same
place. You don't like environment variables and have advanced two
hypothetical issues with no specific plausible case to back it up. I
have pointed out the utility and desirability otherwise. Frankly, I'm
not sure why you are pushing so hard to make sure that we accomplish
nothing in this area, while minimizing the joys of working out the
issues. In any case, the main work is in the internal mechanisms, not in
the exterior varnish.

From my experience as a designer, developer, and operator of large data
handling systems *without* adequate decoupling of disk topology from
internal resource definitions (Ingres just didn't do it right), I'll
point out that it is an issue. A big issue. With real-life examples to
back it up. If the PostgreSQL solution continues to be an issue, we can
continue to discuss *productive* alternatives. But there is nothing in
the work ahead which paints us into a corner.

As you may already know (read the docs to freshen up if not) environment
variables are not required to be used for the current implementation of
locations. It is supported, and I recommend their use. But absolute
paths can be used also; I implemented both strategies to accommodate the
difference in opinion on the pros and cons of each approach. Nothing has
to be different in the upcoming work. The behavior of initlocation has
been absolutely no burden on -hackers for the nearly *5 years* that it
has been available, and that is the best evidence that we're just
talking through hats. Let's get on with it, or at least get back to
being civil.
               - Thomas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Curt Sampson
Дата:
Сообщение: Re: Rules and Views
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WAL file location