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
Re: mingw configure failure workaround |
Список | 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 по дате отправления: