Re: pgwin32_open returning EINVAL

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: pgwin32_open returning EINVAL
Дата
Msg-id 87bq8rq6ao.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: pgwin32_open returning EINVAL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pgwin32_open returning EINVAL  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> "Andrew Dunstan" <andrew@dunslane.net> writes:
>>> Interesting. Maybe forever is going a bit too far, but retrying for <n>
>>> seconds or so.
>
>> I think looping forever is the right thing. Having a fixed timeout just means
>> Postgres will break sometimes instead of all the time. And it introduces
>> non-deterministic behaviour too.
>
> Looping forever would be considered broken by a very large fraction of
> the community.

Really? I understood we're talking about having Postgres fail with an error if
any of its files are opened by another program such as backup software. So
with a 30s limit it means Postgres might or might not fail depending on how
long this other software has the file open. That doesn't seem like an
improvement.

>
> IIRC we have a 30-second timeout in rename() for Windows, and that seems
> to be working well enough, so I'd be inclined to copy the behavior for
> this case.

I thought it was unlink, and the worst-case there is that we leak a file until
some later time. I'm wasn't exactly following that case though.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!


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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: VLDB Features
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Release Note Changes