Re: mingw configure failure workaround

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: mingw configure failure workaround
Дата
Msg-id 40942AE3.7030308@dunslane.net
обсуждение исходный текст
Ответ на Re: mingw configure failure workaround  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: mingw configure failure workaround  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: mingw configure failure workaround  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Greg Sabino Mullane"
Дата:
Сообщение: Re: Weird prepared stmt behavior
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: mingw configure failure workaround