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

On Mon, 12 Aug 2002, Thomas Lockhart wrote:

> > If you move pg_xlog, you have to create a symlink in /data that points
> > to the new location. Initdb would do that automatically, but if you
> > move it after initdb, you would have to create the symlink yourself.
> > With Thomas's current code, you would add/change PGXLOG instead to point
> > to the new location, rather than modify the symlink.
>
> There is no "the symlink", but of course that tinkering is in no way
> precluded by the new code. Although some seem to like symlinks, others
> (including myself) see no good engineering practice in making them the
> only foundation for distributing files across file systems.

Why? You often say you don't like them, but I have yet to see you say why
you don't like them.

> The patches as-is follow existing PostgreSQL practice,

using environmental variables is a practice we should discontinue if
possible, and use as little as possible. They ARE a security hole waiting
to happen.

> have complete and
> perfect backward compatibility, and do not preclude changes in
> underlying implementation in the future if those who are objecting
> choose to do a complete and thorough job of meeting my objections to the
> current counter-suggestions. As an example, two lines of code in initdb
> would add "the beloved symlink" to $PGDATA, eliminating one objection
> though (of course) one I don't support.
>
> > > One thought at the back of my mind is why not have something like a
> > > 'PG_VERSION' for XLOG? Maybe something so simple as a text file in both
> > > the data and xlog directory that just contains a timestamp from the
> > > initdb? then, when you startup postmaster with a -X option, it compares
> > > the two files and makes sure that they belong to each other?
> > Uh, seems it could get messy, but, yea, that would work. It means
> > adding a file to pg_xlog and /data and somehow matching them. My
> > feeling was that the symlink was unambiguous and allowed for fewer
> > mistakes. I think that was Tom's opinion too.
>
> In the spirit of gratutious overstatement, I'll point out again:
> symlinks are evil. Any sense of a job well done is misplaced if our
> underpinnings rely on them for distributing files across file systems.
> As an ad hoc hack to work around current limitations they may have some
> utility.

Why are symlinks evil? They exist on every major OS I know of, and they
work. They allow the user to quickly point the postgresql engine in
different places, and they are simple and easy to use. I found the use of
environmental variables far more confusing when I first started using
postgresql than symlinks.

In particular, which operating systems does Postgresql run don't have
symlink capability?

> Anyway, istm that this is way too much discussion for a small extension
> of capability, and it has likely cost a table and index "with location"
> implementation for the upcoming release just due to time wasted
> discussing it. Hope it was worth it :/

Well, if it averts a security problem, or makes the database easier to use
in the long run, then it probably was. It may seem like too much
discussion for such a simple topic, but it's not.

My non-coding vote goes with Tom Lane on this. initdb can set pg_xlog,
and if you need to change it, use symlinks. They're safe, secure, and
they just plain work. The only argument I can possibly think of against
the symlink boogie is if there is an os we run on that can't do symlinks.
And then I'd still think it would belong in postgresql.conf, be set by
initdb, and not be an environmental variable.

Of course that's just my opinion, I could be wrong (with apologies to
Dennis Miller)

Scott Marlowe