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

OK, seeing as no one voted, and only Tom and I objected originally, we
will keep the code as Thomas has applied it, namely that PGXLOG/-X is
recognized by initdb, postmaster, postgres, and pg_ctl. There is no
symlink from the /data directory to the WAL location.

Thomas, you mentioned implementing table spaces. Are you planning to
use environment variables there too? You mentioned that Ingres's use of
environment variables wasn't well implemented. How will you improve on
it?

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Thomas Lockhart wrote:
> > > 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? ;)
>
> Uh, conclusions. Sorry. New keyboard desk in new house. :-)
>
> > 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*.
>
> Yep. What bothers me is the clutter to the other commands that allow
> XLOG location specification when you would never really want to specify
> it except as part of initdb. I just see those extra flags as
> cruft/confusion.
>
> Look at pg_ctl:
>
> pg_ctl start [-w] [-D DATADIR] [-s] [-X PGXLOG] [-l FILENAME] [-o "OPTIONS"]
>
> Which option doesn't make sense? -X. It is way beyond the
> functionality of the command.
>
>
> > 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 think anyone agreed with your concerns about symlinks. If you
> want to be careful, do the "ln -s" in initdb and exit on failure, and
> tell them not to use -X on that platform, though we use symlinks for
> postmaster/postgres identification, so I know the only OS that doesn't
> support symlinks is Netware, only because Netware folks just sent in a
> patch to add a -post flag to work around lack of symlinks. (I have
> asked for clarification from them.)
>
> I actually requested a vote, and got several people who wanted my
> compromise (PGXLOG or initdb -X flag only), and I didn't see anyone who
> liked the addition of -X into non-initdb commands. Should I have a
> specific vote? OK, three options:
>
> 1) -X, PGXLOG in initdb, postmaster, postgres, pg_ctl
> 2) -X, PGXLOG in initdb only
> 3) nothing
>
> I remember a number of people liking 2, but we can vote again.
>
> > 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...
>
> I clearly want tablespaces, and it would be great for 7.3, and I don't
> think it is a huge job. However, I think it will require symlinks to be
> usable, and you probably do not, so it may be an issue.
>
> As for the argumentativeness, we do have folks with some strong
> opinions, and I guess on the PGXLOG issue, I am one of them. Maybe that
> is bad? Are people expressing themselves badly? If so, I would like to
> hear details either on list or privately so I can address them.
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073