Re: open item: tablespace handing in pg_dump/pg_restore - Mailing list pgsql-hackers
From | Reini Urban |
---|---|
Subject | Re: open item: tablespace handing in pg_dump/pg_restore |
Date | |
Msg-id | 41653B21.2080302@x-ray.at Whole thread Raw |
In response to | Re: open item: tablespace handing in pg_dump/pg_restore (Reini Urban <rurban@x-ray.at>) |
Responses |
Re: open item: tablespace handing in pg_dump/pg_restore
|
List | pgsql-hackers |
Reini Urban schrieb: > Tom Lane schrieb: >> Bruce Momjian <pgman@candle.pha.pa.us> writes: >> >>> I am confused. CVS has in port.h: >>> so you should already be calling the junction code on Cygwin. > > true. didn't thought of that. very strange. > >> Yeah, I'm sure he is, but it looks from the regression results like it >> doesn't quite work on Cygwin. Is that fixable? > > I'll step that in the debugger. not yet done. >> If so, we'd have a choice of whether to rely on junctions or on >> Cygwin's own emulation of symlinks. I'd be inclined to think the >> former is a better idea, >> if only because it'd give you some chance of migrating a data >> directory between Cygwin and native ports. > > Cygwin can do symlinks for directories via the magic .lnk file. > But Cygwin can also do junctions via hardlinks in ln.exe. > I thought link() calls the junction code. > I'll investigate why the libc link() failed, and if ln.exe does some > sifferent magic, similar to pgsymlink. For the records: Using cygwin native slow symlinks - see attached patch - works fine. Quite an overhead via the magic .lnk file. tablespace tests pass. Should I investigate what users want? 1. speed: * junctions, can only be manipulated via junction.exe (sysinternals.com e.g.) * only w2k and above, 2. or compatibility: * .lnk, can be manipulated with ln.exe * all windows version. even win95 when we fix our outstanding cygserver issues with cygserver ----------------- But another problem arose. Doesn't look like a sideeffect caused by my symlink switch. I switched to latest CVS in between. parallel_schedule always fails after finishing create_misc, independent of the order. If it's the first 2nd, 3rd, ... so it's not create_aggregate or any other test there. This is the tail of postmaster.log: ERROR: aggregate nosuchagg(*) does not exist ERROR: operator does not exist: integer ###### ERROR: syntax error at or near ")" at character 45 ERROR: syntax error at or near "IN" at character 43 ERROR: new row for relation "check_tbl" violates check constraint "check_con" ERROR: new row for relation "check_tbl" violates check constraint "check_con" ERROR: new row for relation "check_tbl" violates check constraint "check_con" ERROR: new row for relation "check2_tbl" violates check constraint "sequence_con" ERROR: new row for relation "check2_tbl" violates check constraint "sequence_con" ERROR: new row for relation "check2_tbl" violates check constraint "sequence_con" ERROR: new row for relation "check2_tbl" violates check constraint "sequence_con" -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ --- postgresql-8.0.0cvs/src/backend/commands/tablespace.c.orig 2004-08-30 04:54:38.000000000 +0200 +++ postgresql-8.0.0cvs/src/backend/commands/tablespace.c 2004-10-07 14:24:11.731406400 +0200 @@ -51,6 +51,10 @@ */ #include "postgres.h" +#ifdef __CYGWIN__ +#undef symlink +#endif + #include <unistd.h> #include <dirent.h> #include <sys/types.h>
pgsql-hackers by date: