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 по дате отправления: