Thread: Re: open item: tablespace handing in pg_dump/pg_restore
> > >>But the regression test fails: (the only failing test > against cvs > > HEAD) > > >>This is not only a pg_dump/pg_restore issue, or? > > >> > > >>-- Will fail with bad path > > >>CREATE TABLESPACE badspace LOCATION '/no/such/location'; > > >>ERROR: could not set permissions on directory > "/no/such/location": > > >>No such file or directory > > >>-- No such tablespace > > >>CREATE TABLE bar (i int) TABLESPACE nosuchspace; > > >>ERROR: tablespace "nosuchspace" does not exist > > >>-- Fail, not empty > > >>DROP TABLESPACE testspace; > > >>ERROR: tablespace "testspace" is not empty DROP SCHEMA > testschema > > >>CASCADE; > > >>NOTICE: drop cascades to table testschema.foo > > >>-- Should succeed > > >>DROP TABLESPACE testspace; > > >> > > >>=> > > >> > > >>*************** > > >>*** 38,45 **** > > >> ERROR: tablespace "nosuchspace" does not exist > > >> -- Fail, not empty > > >> DROP TABLESPACE testspace; > > >>! ERROR: tablespace "testspace" is not empty > > >> DROP SCHEMA testschema CASCADE; > > >>! NOTICE: drop cascades to table testschema.foo > > >> -- Should succeed > > >> DROP TABLESPACE testspace; > > >>--- 41,49 ---- > > >> ERROR: tablespace "nosuchspace" does not exist > > >> -- Fail, not empty > > >> DROP TABLESPACE testspace; > > >>! ERROR: tablespace "testspace" does not exist > > >> DROP SCHEMA testschema CASCADE; > > >>! ERROR: schema "testschema" does not exist > > >> -- Should succeed > > >> DROP TABLESPACE testspace; > > >>+ ERROR: tablespace "testspace" does not exist > > > > > > > > > I cannot recreate on Linux. What platform, etc, are you on? > > > > hmm, I'll investigate then. > > > > postgresql latest CVS with 2 minor shlib building patches left > > (added -lpgport) > > cygwin-1.5.11 > > gcc-3.4.1 > > Hmm.. sounds like we're trying to support tablespaces on a > system which doesn't actually support symlinks (in the way we > need them). Can any of the windows guys help? There was special code added to handle symlinks on windows using NTFS junction points to pgport. Not sure if it's a) enabled, or b) working, under cygwin. Dunno if anyone has even tried it. I'd go looking around that area :-) //Magnus
> > > OK, I have applied the following patch that uses Cygwin native > > > symlink() instead of the Win32 junctions. The reason for this is > > > that Cygwin symlinks work on Win95/98/ME where junction points do > > > not > > > > Is this really a Win95/98/ME vs NT distinction or a FAT32 > vs NTFS distinction? > > In which case does an NT machine that happens to be using a > FAT32 file > > system have the same problem? > > I believe it is OS, not file system. No, it's file system. Junctions will not work on NT OS:es with FAT32. Directory junctions require NTFSv5, which is only available on Windows 2000 and newer. //Magnus
"Magnus Hagander" <mha@sollentuna.net> writes: > No, it's file system. > Junctions will not work on NT OS:es with FAT32. > Directory junctions require NTFSv5, which is only available on Windows > 2000 and newer. So then there really has to be a run-time check for this. Either at initdb time, or at the time the database tries to create the link. You can't know at compile-time whether the filesystem the database will be on will support junctions. -- greg
Magnus Hagander wrote: > > > > OK, I have applied the following patch that uses Cygwin native > > > > symlink() instead of the Win32 junctions. The reason for this is > > > > that Cygwin symlinks work on Win95/98/ME where junction points do > > > > not > > > > > > Is this really a Win95/98/ME vs NT distinction or a FAT32 > > vs NTFS distinction? > > > In which case does an NT machine that happens to be using a > > FAT32 file > > > system have the same problem? > > > > I believe it is OS, not file system. > > No, it's file system. > Junctions will not work on NT OS:es with FAT32. > Directory junctions require NTFSv5, which is only available on Windows > 2000 and newer. My point was that junctions don't exist on Win98 no matter what file system you use. I don't think the API even exists on those OS's, never mind what file system you have. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
>> > > > OK, I have applied the following patch that uses Cygwin native >> > > > symlink() instead of the Win32 junctions. The reason >for this is >> > > > that Cygwin symlinks work on Win95/98/ME where >junction points do >> > > > not >> > > >> > > Is this really a Win95/98/ME vs NT distinction or a FAT32 >> > vs NTFS distinction? >> > > In which case does an NT machine that happens to be using a >> > FAT32 file >> > > system have the same problem? >> > >> > I believe it is OS, not file system. >> >> No, it's file system. >> Junctions will not work on NT OS:es with FAT32. >> Directory junctions require NTFSv5, which is only available >on Windows >> 2000 and newer. > >My point was that junctions don't exist on Win98 no matter what file >system you use. I don't think the API even exists on those OS's, never >mind what file system you have. The API exists - it's just a call to DeviceIOControl(). That one exists on all win32 platforms. It will return a "not supported" error value, but the API is there. (Unlike some other APIs where the program won't even start because the entrypoint is not present in the system DLLs) The only reason they are not in 9x is that 9x does not support NTFS. The function is implemented only in the filesystem, not in the OS itself. //Magnus