> >>> Tom Lane <[EMAIL PROTECTED]> >>>
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> > None of this seems material, however. It's pretty clear that the
> > problem was exhaustion of the Windows page pool.
> > ...
> > If we don't want to tell Windows users to make highly technical
> > changes to the Windows registry in order to use PostgreSQL, it does
> > seem wise to use retries, as has already been discussed on this
> > thread.
>
> Would a simple retry loop actually help? It's not clear to
> me how persistent such a failure would be.
(Not sure why I didn't get Toms mail - lists acting up again? Anyway, I
got Kevins response, but am responding primarily to Tom)
The way I read it, a delay should help. It's basically running out of
kernel buffers, and we just delay, somebody else (another process, or an
IRQ handler, or whatever) should get finished with their I/O, free up
the buffer, and let us have it. Looking around a bit I see several
references that you should retry on it, but nothing in the API docs.
I do think it's probably a good idea to do a short delay before retrying
- at least to yield the CPU for one slice. That would greatly increase
the probability of someone else finishing their I/O...
That's how I read it, but I'm not 100% sure.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
