Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is *still* broken)
| От | Tom Lane |
|---|---|
| Тема | Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is *still* broken) |
| Дата | |
| Msg-id | 20891.1496767442@sss.pgh.pa.us обсуждение |
| Ответ на | Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken) (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)
Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken) |
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> I think the idea of retrying process creation (and I definitely agree
> with Tom and Magnus that we have to retry process creation, not just
> individual mappings) is a good place to start. Now if we find that we
> are having to retry frequently, then I think we might need to try
> something along the lines of what Andres proposed and what nginx
> apparently did. However, any fixed address will be prone to
> occasional failures (or maybe, on some systems, regular failures) if
> that particular address happens to get claimed by something. I don't
> think we can say that there is any address where that definitely won't
> happen. So I would say let's do this retry thing first, and then if
> that proves inadequate, we can also try moving the mappings to a range
> where conflicts are less likely.
By definition, the address range we're trying to reuse worked successfully
in the postmaster process. I don't see how forcing a specific address
could do anything but create an additional risk of postmaster startup
failure.
regards, tom lane
В списке pgsql-hackers по дате отправления: