Re: WAL file location - Mailing list pgsql-hackers
From | Thomas Lockhart |
---|---|
Subject | Re: WAL file location |
Date | |
Msg-id | 3D477A37.1E507C2B@fourpalms.org Whole thread Raw |
In response to | Re: WAL file location (Curt Sampson <cjs@cynic.net>) |
Responses |
Re: WAL file location
|
List | 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 by date: