From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Tony Wasson" <ajwasson(at)gmail(dot)com> |
Cc: | "Sean Davis" <sdavis2(at)mail(dot)nih(dot)gov>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: FATAL: could not read statistics message |
Date: | 2006-05-16 23:06:46 |
Message-ID: | 13096.1147820806@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Tony Wasson" <ajwasson(at)gmail(dot)com> writes:
> When I saw the same error as you, the stats collector process was
> missing.
The collector, or the buffer process? The reported message would be
emitted by the buffer process, after which it would immediately exit.
(The collector would go away too once it noticed EOF on its input.)
By and by the postmaster should start a fresh pair of processes.
IIRC, the postmaster's spawning is rate-limited to once a minute,
so if the new buffer were immediately dying with the same error,
that would explain your observation of once-a-minute messages.
This all still leaves us no closer to understanding *why* the recv()
is failing, though. What it does suggest is that the problem is a
hard, repeatable error when it does occur, which makes me loath to
put in the quick-fix "retry on EAGAIN" that I previously suggested.
If it is a hard error then that will just convert the problem into
a busy-loop that'll eat all your CPU cycles ... not much of an
improvement ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-16 23:15:13 | Re: Partitioning on ip4 datatype using <<= |
Previous Message | Tom Lane | 2006-05-16 22:53:36 | Re: bytea hex input/output |