stat() vs cygwin
in [PgSql]
|
From: Bruce Momjian on 23 Jun 2008 17:40 Magnus, was this fixed/resolved? --------------------------------------------------------------------------- Magnus Hagander wrote: > It seems my fix for stat() broke cygwin, because it doesn't have > dosmaperr() available. The way I see it there are two ways to fix this: > > 1) Don't apply the stat fix for cygwin. > > 2) Make our dosmaperr() function be used on cygwin. > > > I don't know if the fix is actually needed on cygwin. Can someone with > access to such an environment test it and see? > > The easy check, easier than the table, goes something along the line > of: > CREATE TABLE test(t int); > INSERT INTO test(t) SELECT * FROM generate_series(1,100000); > SELECT pg_relation_size('t'); > SELECT pg_sleep(5); > SELECT pg_relation_size('t'); > > > Without the patch on win32, the first pg_relation_size comes out as 0, > and the second one correct. With the patch, they come out equal. They > should, of course, always come out equal. > > //Magnus > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 24 Jun 2008 04:32 Yes. As in the cygwin build does build. Nobody really has verified if the fix is needed there. But frankly, if you are likely to care about the effects of this issue, you won't be running cygwin anyway. It's mostly a dead platform for postgresql anyway, AFAICS we only keep it building for legacy compatibility. Once it starts taking lots of resources to keep building (which it doesn't now), I think we should just drop it instead... //Magnus Bruce Momjian wrote: > Magnus, was this fixed/resolved? > > --------------------------------------------------------------------------- > > Magnus Hagander wrote: >> It seems my fix for stat() broke cygwin, because it doesn't have >> dosmaperr() available. The way I see it there are two ways to fix this: >> >> 1) Don't apply the stat fix for cygwin. >> >> 2) Make our dosmaperr() function be used on cygwin. >> >> >> I don't know if the fix is actually needed on cygwin. Can someone with >> access to such an environment test it and see? >> >> The easy check, easier than the table, goes something along the line >> of: >> CREATE TABLE test(t int); >> INSERT INTO test(t) SELECT * FROM generate_series(1,100000); >> SELECT pg_relation_size('t'); >> SELECT pg_sleep(5); >> SELECT pg_relation_size('t'); >> >> >> Without the patch on win32, the first pg_relation_size comes out as 0, >> and the second one correct. With the patch, they come out equal. They >> should, of course, always come out equal. >> >> //Magnus >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Dave Page" on 24 Jun 2008 04:47 On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander <magnus(a)hagander.net> wrote: > Yes. > > As in the cygwin build does build. Nobody really has verified if the fix > is needed there. But frankly, if you are likely to care about the > effects of this issue, you won't be running cygwin anyway. It's mostly a > dead platform for postgresql anyway, AFAICS we only keep it building for > legacy compatibility. Once it starts taking lots of resources to keep > building (which it doesn't now), I think we should just drop it instead... FWIW, the most recent packages from Cygwin themselves are 8.2.5. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Kenneth Marshall on 24 Jun 2008 08:28 One motivation for keeping it working on Cygwin, is that in some environments it is not allowed to install native Windows apps but they allow the use of the Cygwin environment. Of course if it takes too many resources to support, then dropping support would be an option. I would check this for you, but I am in the middle of moving and my Windows/Cygwin box is not available right now. Cheers, Ken On Tue, Jun 24, 2008 at 10:32:08AM +0200, Magnus Hagander wrote: > Yes. > > As in the cygwin build does build. Nobody really has verified if the fix > is needed there. But frankly, if you are likely to care about the > effects of this issue, you won't be running cygwin anyway. It's mostly a > dead platform for postgresql anyway, AFAICS we only keep it building for > legacy compatibility. Once it starts taking lots of resources to keep > building (which it doesn't now), I think we should just drop it instead... > > //Magnus > > Bruce Momjian wrote: > > Magnus, was this fixed/resolved? > > > > --------------------------------------------------------------------------- > > > > Magnus Hagander wrote: > >> It seems my fix for stat() broke cygwin, because it doesn't have > >> dosmaperr() available. The way I see it there are two ways to fix this: > >> > >> 1) Don't apply the stat fix for cygwin. > >> > >> 2) Make our dosmaperr() function be used on cygwin. > >> > >> > >> I don't know if the fix is actually needed on cygwin. Can someone with > >> access to such an environment test it and see? > >> > >> The easy check, easier than the table, goes something along the line > >> of: > >> CREATE TABLE test(t int); > >> INSERT INTO test(t) SELECT * FROM generate_series(1,100000); > >> SELECT pg_relation_size('t'); > >> SELECT pg_sleep(5); > >> SELECT pg_relation_size('t'); > >> > >> > >> Without the patch on win32, the first pg_relation_size comes out as 0, > >> and the second one correct. With the patch, they come out equal. They > >> should, of course, always come out equal. > >> > >> //Magnus > >> > >> -- > >> Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > >> To make changes to your subscription: > >> http://www.postgresql.org/mailpref/pgsql-hackers > > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 24 Jun 2008 08:35 Kenneth Marshall wrote: > One motivation for keeping it working on Cygwin, is that in some > environments it is not allowed to install native Windows apps but > they allow the use of the Cygwin environment. Of course if it takes > too many resources to support, then dropping support would be an > option. I would check this for you, but I am in the middle of moving > and my Windows/Cygwin box is not available right now. Does anybody seriously have such a broken policy? I know a lot of places who have inverse policy, where they don't allow cygwin, but I've never heard of anybody refusing native programs and only allowing cygwin. Just like I've heard of no linux shops requiring that you run your database under wine... //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 Prev: Kludge in pg_standby.c Next: Dept of ugly hacks: eliminating padding space in systemindexes |