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

> Thomas, would you remind me of the concusions because I thought everyone
> involved felt that it should be an initdb-only option, but I still see
> it in CVS.

?? "Concussions" as in brain bruises? ;)

I'm not sure I understand the question. I assume that we are talking
about the WAL log location feature I implemented recently. It is an
initdb-only option, and defaults to the current behavior *exactly*.

The new feature is to allow an argument to initdb to locate the WAL file
to another location. That location can be specified on the command line,
or through an environment variable. Neither form precludes use of the
other, and either form can be considered "best practice" depending on
your opinion of what that is.

The postmaster also recognizes the command line option and environment
variable. The only suggestion I got as an alternative involved soft
links, which is not portable, which is not robust, and which is not used
anywhere else in the system. If we moved toward relying on soft links
for distributing resources we will be moving in the wrong direction for
many reasons, some of which I've mentioned previously. GUC parameters
were also mentioned as a possibility, and the infrastructure does not
preclude that at any time.

I don't recall that there were very many folks "involved". There were
several opinions, though most were from folks who were not thinking of
implementing disk management features. Some opinions dealt with details,
and some seemed to deal with the wisdom of allowing anything other than
a "one partition" model of the database, which is nothing if not short
sighted. Current default behavior is as first implemented, and the new
feature allows locating the WAL logs in another area. For the current
state of the art, that seems competitive with features found in other
database products, and an essential step in teaching PostgreSQL to work
with very large databases.

I had thought to extend the capabilities to allow resource allocation
for individual tables and indices, which has *long* been identified as a
desired capability by folks who are managing large systems. It seemed
reasonable to have done in time for 7.3. I'm rethinking that, not
because it shouldn't happen, but because the process of discussing these
issues has become so argumentative, divisive, impolite, and unpleasant.
Which is a shame imho...

- Thomas