Re: open item: tablespace handing in pg_dump/pg_restore - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: open item: tablespace handing in pg_dump/pg_restore
Date
Msg-id 200410112249.i9BMnc216124@candle.pha.pa.us
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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: open item: tablespace handing in pg_dump/pg_restore  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
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@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>

>
> ---------------------------(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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
Index: src/include/port.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port.h,v
retrieving revision 1.63
diff -c -c -r1.63 port.h
*** src/include/port.h    27 Sep 2004 23:24:37 -0000    1.63
--- src/include/port.h    11 Oct 2004 22:36:50 -0000
***************
*** 167,174 ****
   */
  extern int    pgrename(const char *from, const char *to);
  extern int    pgunlink(const char *path);
- extern int    pgsymlink(const char *oldpath, const char *newpath);
-
  /* Include this first so later includes don't see these defines */
  #ifdef WIN32_CLIENT_ONLY
  #include <io.h>
--- 167,172 ----
***************
*** 176,184 ****
--- 174,193 ----

  #define rename(from, to)        pgrename(from, to)
  #define unlink(path)            pgunlink(path)
+
+ /*
+  *    Cygwin has its own symlinks which work on Win95/98/ME where
+  *    junction points don't work, so use it instead.  We have no
+  *    way of knowing what type of system Cygwin binaries will be
+  *    run on.
+  */
+ #ifdef WIN32
+ extern int    pgsymlink(const char *oldpath, const char *newpath);
  #define symlink(oldpath, newpath)    pgsymlink(oldpath, newpath)
  #endif

+ #endif
+
  extern bool rmtree(char *path, bool rmtopdir);

  #ifdef WIN32
Index: src/port/dirmod.c
===================================================================
RCS file: /cvsroot/pgsql/src/port/dirmod.c,v
retrieving revision 1.27
diff -c -c -r1.27 dirmod.c
*** src/port/dirmod.c    27 Sep 2004 19:16:02 -0000    1.27
--- src/port/dirmod.c    11 Oct 2004 22:36:53 -0000
***************
*** 142,147 ****
--- 142,148 ----
  }


+ #ifdef WIN32    /* Cygwin has its own symlinks */
  /*
   *    pgsymlink support:
   *
***************
*** 160,168 ****
      WORD        PrintNameOffset;
      WORD        PrintNameLength;
      WCHAR        PathBuffer[1];
! }
!
!             REPARSE_JUNCTION_DATA_BUFFER;

  #define REPARSE_JUNCTION_DATA_BUFFER_HEADER_SIZE   \
          FIELD_OFFSET(REPARSE_JUNCTION_DATA_BUFFER, SubstituteNameOffset)
--- 161,167 ----
      WORD        PrintNameOffset;
      WORD        PrintNameLength;
      WCHAR        PathBuffer[1];
! }    REPARSE_JUNCTION_DATA_BUFFER;

  #define REPARSE_JUNCTION_DATA_BUFFER_HEADER_SIZE   \
          FIELD_OFFSET(REPARSE_JUNCTION_DATA_BUFFER, SubstituteNameOffset)
***************
*** 246,251 ****
--- 245,251 ----
      return 0;
  }
  #endif
+ #endif


  /* We undefined this above, so we redefine it */

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Need for DLLINIT in Makefile.shlib
Next
From: Tom Lane
Date:
Subject: Re: open item: tablespace handing in pg_dump/pg_restore