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  (Tom Lane <tgl@sss.pgh.pa.us>)
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:

Previous
From: Curt Sampson
Date:
Subject: Re: Rules and Views
Next
From: Tom Lane
Date:
Subject: Re: WAL file location