Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> delay. I just stuck a fixed 100msec delay into the accept-failed code
>>> path.
>>
>> Seems worth mentioning that bgwriter sleeps 1 sec in case of failure.
>> (And so does the autovac code I'm currently look
Alvaro Herrera wrote:
Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
We could possibly sleep() a bit before retrying,
just to not suck 100% CPU, but that doesn't really *fix* anything ...
Well, not only that, but the
Tom Lane wrote:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
> >> We could possibly sleep() a bit before retrying,
> >> just to not suck 100% CPU, but that doesn't really *fix* anything ...
>
> > Well, not only that, but the machine is currently writing
Jim Nasby <[EMAIL PROTECTED]> writes:
> On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
>> We could possibly sleep() a bit before retrying,
>> just to not suck 100% CPU, but that doesn't really *fix* anything ...
> Well, not only that, but the machine is currently writing to the
> postmaster log a
On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
Interesting. So accept() fails because it can't allocate an FD, which
means that the select condition isn't cleared, so we keep retrying
forever. I don't see what else we could do though. Having the
postmaster abort on what might well be a transien
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> The postmaster is stuck in the following loop, according to
> ktrace/kdump:
> 2023 postgres CALL select(0x8,0xbfffe194,0,0,0xbfffe16c)
> 2023 postgres RET select 1
> 2023 postgres CALL sigprocmask(0x3,0x2f0d38,0)
> 2023 postgres RET sigpro
The 8.1 build for cuckoo is currently hung, with the *postmaster* taking
all the CPU it can get. The build started almost 5 hours ago.
The postmaster is stuck in the following loop, according to
ktrace/kdump:
2023 postgres RET write 59/0x3b
2023 postgres CALL close(0x)
2023 postg
