From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: mingw configure failure workaround |
Date: | 2004-05-01 22:55:31 |
Message-ID: | 40942AE3.7030308@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-hackers-win32 pgsql-patches |
Tom Lane wrote:
>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>The real issue in my mind is why is "ln" unreliable in mingw? I cannot
>>>see any point in a retry kluge when we do not know what's really going
>>>on.
>>>
>>>
>
>
>
>>I'm still trying to find out. But I don't see why this is different from
>>the kludge we already have for unlink, and that one is right inside
>>postgresql.
>>
>>
>
>It's different because we know why we need that one: we understand the
>cause of the behavior and we therefore can have some confidence that the
>kluge will fix it (or not, as the case may be). I have zero confidence
>in looping five times around an "ln" call.
>
>
>
Even if we don't do that can we *please* put in something that detects
the error, and tells the user what they will have to do to fix it?
Failing in a situation which we know we can detect and not telling the
user is intolerable, IMNSHO.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-05-02 03:08:33 | Re: mingw configure failure workaround |
Previous Message | Greg Sabino Mullane | 2004-05-01 22:16:56 | Re: Weird prepared stmt behavior |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-05-02 03:08:33 | Re: mingw configure failure workaround |
Previous Message | Tom Lane | 2004-05-01 21:43:06 | Re: mingw configure failure workaround |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-05-02 03:08:33 | Re: mingw configure failure workaround |
Previous Message | Bruce Momjian | 2004-05-01 22:08:22 | Re: FW: Timezone library |