Re: [CYGWIN] open item: tablespace handing in pg_dump/pg_restore
От | Reini Urban |
---|---|
Тема | Re: [CYGWIN] open item: tablespace handing in pg_dump/pg_restore |
Дата | |
Msg-id | 416D1985.7000909@x-ray.at обсуждение исходный текст |
Список | pgsql-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 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@postgresql.org [mailto:pgsql-cygwin-owner@postgresql.org]On Behalf Of Tom Lane > Sent: Tuesday, October 12, 2004 1:02 AM > To: Bruce Momjian > Cc: Reini Urban; PostgreSQL Developers; pgsql-cygwin@postgresql.org > Subject: Re: [CYGWIN] [HACKERS] open item: tablespace handing in pg_dump/pg_restore > > > Bruce Momjian <pgman@candle.pha.pa.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/
В списке pgsql-hackers по дате отправления: