Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, soculicidae is *still* broken)
От | Noah Misch |
---|---|
Тема | Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, soculicidae is *still* broken) |
Дата | |
Msg-id | 20170525022344.GA104533@gust.leadboat.com обсуждение исходный текст |
Ответ на | Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken) (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, soculicidae is *still* broken)
|
Список | pgsql-hackers |
On Wed, May 24, 2017 at 09:29:11AM -0400, Michael Paquier wrote: > On Tue, May 23, 2017 at 8:14 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > So it seems both you and Tom are leaning towards some sort of retry > > mechanism for shm reattach on Windows. I also think that is a viable > > option to negate the impact of ASLR. Attached patch does that. Note > > that, as I have mentioned above I think we need to do it for shm > > reserve operation as well. I think we need to decide how many retries > > are sufficient before bailing out. As of now, I have used 10 to have > > some similarity with PGSharedMemoryCreate(), but we can choose some > > different count as well. One might say that we can have "number of > > retries" as a guc parameter, but I am not sure about it, so not used. > > New GUCs can be backpatched if necessary, though this does not seem > necessary. Who is going to set up that anyway if we have a limit high > enough. 10 looks like a sufficient number to me. Ten feels low to me. The value should be be low enough so users don't give up and assume a permanent hang, but there's little advantage to making it lower. I'd set it such that we give up in 1-5s on a modern Windows machine, which I expect implies a retry count of one hundred or more.
В списке pgsql-hackers по дате отправления: