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
>
