ROTECTED]
Subject: Re: [CYGWIN] [HACKERS] open item: tablespace handing in pg_dump/pg_restore
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, I have applied the following patch that uses Cygwin native symlink()
> instead of the Win32 junctions. The reason for this is that Cygwin
>
>> > > > 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 distinc
to other machines.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
Sent: Tuesday, October 12, 2004 1:02 AM
To: Bruce Momjian
Cc: Reini Urban; PostgreSQL Developers; [EMAIL PROTECTED]
Subject: Re: [CYGWIN] [HACKERS] open item: tablespace handing in pg_dum
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
Bruce Momjian schrieb:
Greg Stark wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
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
"Magnus Hagander" <[EMAIL PROTECTED]> 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 a
> > > 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
Greg Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > 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
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 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
Bruce Momjian schrieb:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
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
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > 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 kn
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 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 run
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
Reini Urban schrieb:
Tom Lane schrieb:
Bruce Momjian <[EMAIL PROTECTED]> 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'
Tom Lane schrieb:
Bruce Momjian <[EMAIL PROTECTED]> 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 Cy
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am confused. CVS has in port.h:
> so you should already be calling the junction code on Cygwin.
Yeah, I'm sure he is, but it looks from the regression results like it
doesn't quite work on Cygwin. Is that fixable? If so, we'd have a
choice of whethe
Reini Urban <[EMAIL PROTECTED]> writes:
> Somethink like the attached patch is easier.
> Just replace symlink() for dirs with link() #ifdef __CYGWIN__
Wouldn't it be cleaner to #define symlink as link?
regards, tom lane
---(end of broadcast)--
Reini Urban schrieb:
Tom Lane schrieb:
Gavin Sherry <[EMAIL PROTECTED]> writes:
I though this may have been the problem. configure.in defines
HAVE_SYMLINK
to 1 if we are win32. It seems that for Reini's case we are setting our
template (and PORTNAME) to win32 when I suspect it should be cygwin.
An
I am confused. CVS has in port.h:
#if defined(WIN32) || defined(__CYGWIN__)
/*
* Win32 doesn't have reliable rename/unlink during concurrent access,
* and we need special code to do symlinks.
*/
extern int pgrename(const char *from, c
Tom Lane schrieb:
Gavin Sherry <[EMAIL PROTECTED]> writes:
I though this may have been the problem. configure.in defines HAVE_SYMLINK
to 1 if we are win32. It seems that for Reini's case we are setting our
template (and PORTNAME) to win32 when I suspect it should be cygwin.
Anyone got any ideas?
Wh
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I though this may have been the problem. configure.in defines HAVE_SYMLINK
> to 1 if we are win32. It seems that for Reini's case we are setting our
> template (and PORTNAME) to win32 when I suspect it should be cygwin.
> Anyone got any ideas?
What are th
On Mon, 4 Oct 2004, Reini Urban wrote:
> Reini Urban schrieb:
> > no HAVE_SYMLINK defined, though CYGWIN should added -DHAVE_SYMLINK.
>
> oops, sorry for the noise. of course CYGWIN has it defined in pg_config.h.
> CYGWIN can only do hardlinks (junctions) on directories of course.
>
> maybe HAVE_S
On Mon, 4 Oct 2004, Reini Urban wrote:
> Gavin Sherry schrieb:
> > On Mon, 4 Oct 2004, Reini Urban wrote:
> >>>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 -lpg
Reini Urban schrieb:
no HAVE_SYMLINK defined, though CYGWIN should added -DHAVE_SYMLINK.
oops, sorry for the noise. of course CYGWIN has it defined in pg_config.h.
CYGWIN can only do hardlinks (junctions) on directories of course.
maybe HAVE_SYMLINKS should be extended to HAVE_DIR_SYMLINKS when you
Gavin Sherry schrieb:
On Mon, 4 Oct 2004, Reini Urban wrote:
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 ta
> > >>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
On Mon, 4 Oct 2004, Reini Urban wrote:
> Gavin Sherry schrieb:
> > On Mon, 4 Oct 2004, Reini Urban wrote:
> >>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 bad
Gavin Sherry schrieb:
On Mon, 4 Oct 2004, Reini Urban wrote:
>>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 permissi
On Mon, 4 Oct 2004, Reini Urban wrote:
> 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 direc
Bruce Momjian schrieb:
Fabien COELHO wrote:
Dear hackers,
I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted
out.
ISTM that the tablespace handling or ignoring in pg_dump/pg_restore is
still an open issue in current CVS head... waiting for a proper
implementation after the
Fabien COELHO wrote:
>
> Dear hackers,
>
> > I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted
> > out.
>
> ISTM that the tablespace handling or ignoring in pg_dump/pg_restore is
> still an open issue in current CVS head... waiting for a proper
> implementation after t
Dear hackers,
> I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted
> out.
ISTM that the tablespace handling or ignoring in pg_dump/pg_restore is
still an open issue in current CVS head... waiting for a proper
implementation after the brain-storming on what seemed to be
32 matches
Mail list logo
