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

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

From: 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-13 12:03:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-cygwinpgsql-hackers
Leeuw van der, Tim schrieb:
> There are certainly cygwin-users trying out PostgreSQL on cygwin on
>WinXX. If the newest cygwin-version will suddenly stop working under
>WinXX, they will not be happy.

That's why we use cygwin symlinks, not junctions.

> I've given consideration to the argument that you can no longer take
>data-directories from the cygwin-version to the native-version... And I
>think that there's not a *huge* loss there. For me, as an observer and
>occiasional user/developer, I think the loss of not running on
>cygwin+winXX is larger.
> After all, the data can still be dumped / reloaded. And what gives me
>the certainty that the two versions of PostgreSQL, the cygwin and the
>native version, are not already compiled in such way that they're not
>binary compatible? (remember, I'm an outsider on this, with no knowledge
>of the binary formats, and I'm trying to remain in that perspective for
>this discussion)

See below. Conflicting --enable-integer-datetimes and --enable-multibyte 
would be an issue. I don't know if and how our converters handle 
multibyte/non-multibyte, when the backend changes.

> I don't know what the failure will be when you now try to move a
>data-directory from the cygwin version to the native version, when
>cygwin uses a .lnk hack and native uses a junction. Did anyone try? What
>do the results look like? Is there an acceptable way to stop ppl from
>trying / give sensible errors without introducing too much crap in the
>code and without harming ppls data?

That's a non-critical issue. You can always replace the cygwin .lnk dir 
with an actual junction on cygwin also. You'd need to be superuser and 
use "ln -d" or get "junction" from
But than you must have NTFS4 (same drive) or NTFS5 (other local drive).

You can also replace the junction with a cygwin .lnk if you switch to 
FAT, but then you MUST use the cygwin binaries on the data.
Or don't use tablespace at all. It's a pretty esoteric feature at all.

But it will get problematic on big/little endian machine changes, and 
different integer sizes. Don't know if the data is converted on the fly 
then. I only know of AutoCAD's DWG: they designed its data format and 
accessors to be machine and CPU independent. And you usually don't copy 
machine dependent /usr/share/postgresql trees to other machines.

> -----Original Message-----
> From: pgsql-cygwin-owner(at)postgresql(dot)org [mailto:pgsql-cygwin-owner(at)postgresql(dot)org]On Behalf Of Tom Lane
> Sent: Tuesday, October 12, 2004 1:02 AM
> To: Bruce Momjian
> Cc: Reini Urban; PostgreSQL Developers; pgsql-cygwin(at)postgresql(dot)org
> Subject: Re: [CYGWIN] [HACKERS] open item: tablespace handing in pg_dump/pg_restore 
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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 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 think this is probably a net loss, because what it will mean is that
> you cannot take a data directory built under a Cygwin postmaster and use
> it under a native postmaster, nor vice versa.  Given the number of other
> ways in which we do not support pre-NT4 Windows systems, what is the
> benefit of allowing this one?

Reini Urban

In response to

pgsql-cygwin by date

Next:From: Marek LewczukDate: 2004-10-15 07:36:48
Subject: postgresql 8.0 with cygwin - success
Previous:From: Dave PageDate: 2004-10-13 11:59:42
Subject: Re: [pgsql-hackers-win32] Static build of libpq fails

pgsql-hackers by date

Next:From: Reini UrbanDate: 2004-10-13 12:21:09
Subject: Re: plans for bitmap indexes?
Previous:From: Hannu KrosingDate: 2004-10-13 11:51:57
Subject: Re: plans for bitmap indexes?

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