Re: Big 7.1 open items - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: Big 7.1 open items |
Date | |
Msg-id | 4448.961601289@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Big 7.1 open items (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Responses |
RE: Big 7.1 open items
RE: Big 7.1 open items |
List | pgsql-hackers |
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > Well, as y'all have noticed, I think there are strong reasons to use > environment variables to manage locations, and that symlinks are a > potential portability and robustness problem. Reasons? Evidence? > An additional point which has relevance to this whole discussion: > In the future we may allow system resource such as tables to carry names > which use multi-byte encodings. afaik these encodings are not allowed to > be used for physical file names, and even if they were the utility of > using standard operating system utilities like ls goes way down. Good point, although in one sense a string is a string --- as long as we don't allow embedded nulls in server-side encodings, we could use anything that Postgres thought was a name in a filename, and the OS should take it. But if your local ls doesn't show it the way you see in Postgres, the usefulness of having the tablename in the filename goes way down. > istm that from a portability and evolutionary standpoint OID-only file > names (or at least file names *not* based on relation/class names) is a > requirement. No argument from me ;-). I've been looking for compromise positions but I still think that pure numeric filenames are the cleanest solution. There's something else that should be taken into account: for WAL, the log will need to record the table file that each insert/delete/update operation affects. To do that with the smgr-token-is-a-pathname approach I was suggesting yesterday, I think you have to record the database name and pathname in each WAL log entry. That's 64 bytes/log entry which is a *lot*. If we bit the bullet and restricted ourselves to numeric filenames then the log would need just four numeric values:database OIDtablespace OIDrelation OIDrelation versionnumber (this set of 4 values would also be an smgr file reference token). 16 bytes/log entry looks much better than 64. At the moment I can recall the following opinions: Pure OID filenames: Thomas, Tom, Marc, Peter E. OID+relname filenames: Bruce Vadim was in the pure-OID camp a few months ago, but I won't presume to list him there now since he hasn't been involved in this most recent round of discussions. I'm not sure where anyone else stands... but at least in terms of the core group it's pretty clear where the majority opinion is. regards, tom lane
pgsql-hackers by date: