Обсуждение: pgsql/src/include/storage (buf_internals.h relfilenode.h smgr.h)
Date: Monday, October 16, 2000 @ 10:52:28 Author: vadim Update of /home/projects/pgsql/cvsroot/pgsql/src/include/storage from hub.org:/home/projects/pgsql/tmp/cvs-serv67283/include/storage Modified Files: buf_internals.h relfilenode.h smgr.h ----------------------------- Log Message ----------------------------- New file naming. Database OID is used as "tablespace" id and relation OID is used as file node on creation but may be changed later if required. Regression Tests Approved (c) -:)))
* Vadim B. Mikheev - CVS <vadim@postgresql.org> [001016 07:53] wrote: > Date: Monday, October 16, 2000 @ 10:52:28 > Author: vadim > > Update of /home/projects/pgsql/cvsroot/pgsql/src/include/storage > from hub.org:/home/projects/pgsql/tmp/cvs-serv67283/include/storage > > Modified Files: > buf_internals.h relfilenode.h smgr.h > > ----------------------------- Log Message ----------------------------- > > New file naming. Database OID is used as "tablespace" id and > relation OID is used as file node on creation but may be changed later > if required. Regression Tests Approved (c) -:))) Does this mean that the table/index/etc name isn't dependant on the filesystem name anymore? we had some messy situations because a backend crash left us with files in our database directory that made it impossible for postgresql to create indecies because of conflicts. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein <bright@wintelcom.net> writes: > Does this mean that the table/index/etc name isn't dependant on > the filesystem name anymore? Right. This should clean up the situations where a failed table create/ drop/rename leaves a conflicting filename in the directory. regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [001016 09:08] wrote: > Alfred Perlstein <bright@wintelcom.net> writes: > > Does this mean that the table/index/etc name isn't dependant on > > the filesystem name anymore? > > Right. This should clean up the situations where a failed table create/ > drop/rename leaves a conflicting filename in the directory. woohoo! :) 7.1 is shaping up to be the coolest. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein <bright@wintelcom.net> writes: > woohoo! :) > 7.1 is shaping up to be the coolest. I've only been around this project since 6.3.2. When 6.4 came out, it was a big improvement. When 6.5 came out, *that* was a big improvement. When 7.0 came out, it was a huge improvement. 7.1 is looking like another huge improvement. I like the trend. regards, tom lane