Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Reini Urban <rurban(at)x-ray(dot)at>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>,pgsql-cygwin(at)postgresql(dot)org
Subject: Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Date: 2004-10-11 22:49:38
Message-ID: 200410112249.i9BMnc216124@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-cygwinpgsql-hackerspgsql-hackers-win32
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 and we have no
way to know what system will be running the Cygwin binaries so the
safest bet is to use the Cygwin versions.  On Win32 native we only run
on systems that support junctions.

I assume you can make directory symlinks on Cygwin.  Was there some
issue that symlinks 

---------------------------------------------------------------------------

Reini Urban wrote:
> Reini Urban schrieb:
> > Tom Lane schrieb:
> >> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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>

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faqs/FAQ.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-cygwin by date

Next:From: Tom LaneDate: 2004-10-11 23:02:28
Subject: Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Previous:From: Bruce MomjianDate: 2004-10-11 22:22:57
Subject: Need for DLLINIT in Makefile.shlib

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-10-11 23:02:28
Subject: Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Previous:From: Bruce MomjianDate: 2004-10-11 22:22:57
Subject: Need for DLLINIT in Makefile.shlib

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2004-10-11 23:02:28
Subject: Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Previous:From: Bruce MomjianDate: 2004-10-11 22:22:57
Subject: Need for DLLINIT in Makefile.shlib

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group