> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])