Re: stat() vs cygwin - Mailing list pgsql-hackers

From Kenneth Marshall
Subject Re: stat() vs cygwin
Date
Msg-id 20080624122801.GX337@it.is.rice.edu
Whole thread Raw
In response to Re: stat() vs cygwin  (Magnus Hagander <magnus@hagander.net>)
Responses Re: stat() vs cygwin  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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@postgresql.org)
> >> To make changes to your subscription:
> >> http://www.postgresql.org/mailpref/pgsql-hackers
> > 
> 
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
> 


pgsql-hackers by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: Dept of ugly hacks: eliminating padding space in system indexes
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout