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

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 sysinternals.com.
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
http://xarch.tu-graz.ac.at/home/rurban/