On Thu, Jun 16, 2005 at 10:32:46AM -0400, Tom Lane wrote:
> "Ilja Golshtein" <[EMAIL PROTECTED]> writes:
> > To be honest, I don't quite understand why PG does 'send' again and again,
> > while
> > EPIPE seems to be unrecoverable.
> > Isn't it better to terminate server process?
>
> No. See pre
"Ilja Golshtein" <[EMAIL PROTECTED]> writes:
> To be honest, I don't quite understand why PG does 'send' again and again,
> while
> EPIPE seems to be unrecoverable.
> Isn't it better to terminate server process?
No. See previous discussions in the archives.
(One point is that a long-running qu
>> Are PG admins experienced in determining and killing such zombi-sessions?
>> I mean, may be script or something to do this job exist in nature?
>> > Thanks.
>>
>
>#statement_timeout = 0 # 0 is disabled, in milliseconds
>
>I think if you give this item in postgresql.conf a value, it wil
> Are PG admins experienced in determining and killing such zombi-sessions?
> I mean, may be script or something to do this job exist in nature?
> > Thanks.
>
#statement_timeout = 0 # 0 is disabled, in milliseconds
I think if you give this item in postgresql.conf a value, it will kill
l
>Tom Lane <[EMAIL PROTECTED]> writes:
>If so, I would bet that someone did an unconstrained join (ie SELECT
>the cross product of some large tables) and killed their client instead
>of waiting for the result.
Quite probably if you recall my Yesterday's question about low
speed of queries with m
"Ilja Golshtein" <[EMAIL PROTECTED]> writes:
> At the moment on my Linux box I have process
> 'postmaster' eats all CPU. It corresponds
> with connection closed day before -
> not sure if it was normal disconnect.
> strace shows the process constantly
> makes 'send' syscall with EPIPE result.
