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

> 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.

The patches as-is follow existing PostgreSQL practice, 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.

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 :/

- Thomas