| From: | Magnus Hagander <magnus(at)hagander(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: windows shared memory error |
| Date: | 2009-05-04 14:14:59 |
| Message-ID: | 49FEF863.5040407@hagander.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Magnus Hagander wrote:
>>> The actual 1 second value was completely random - it fixed all the
>>> issues on my test VM at the time. I don't recall exactly the details,
>>> but I do recall having to run a lot of tests before I managed to provoke
>>> an error, and that with the 1 sec thing i could run it for a day of
>>> repeated restarts without any errors.
>
>> Well, my untested hypothesis is that the actual time required is
>> variable, depending on environmental factors such as machine load.
>
> Seems reasonable.
>
>> So testing repeatedly where such factors are constant might not be good
>> enough. That's why I suggested some sort of increasing backoff, in an
>> attempt to be adaptive.
>
> I still think there's absolutely no evidence suggesting that a variable
> backoff is necessary. Given how little this code is going to be
> exercised in the real world, how long will it take till we find out
> if you get it wrong? Use a simple retry loop and be done with it.
+1. Let's keep it as simple as possible for now. I doubt it's actually
dependent on the *failed* call.
Andrew, you want to write up a patch or do you want me to do it?
//Magnus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2009-05-04 14:17:27 | Re: "could not reattach to shared memory" captured in buildfarm |
| Previous Message | Andrew Dunstan | 2009-05-04 14:14:10 | Re: windows shared memory error |