Re: stat() vs cygwin

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: stat() vs cygwin
Date: 2008-06-24 12:28:01
Message-ID: 20080624122801.GX337@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)postgresql(dot)org)
> >> To make changes to your subscription:
> >> http://www.postgresql.org/mailpref/pgsql-hackers
> >
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-06-24 12:29:44 Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Previous Message Heikki Linnakangas 2008-06-24 12:21:48 Re: Dept of ugly hacks: eliminating padding space in system indexes