Re: BUG #3266: SSL broken pipes kill the machine and fill the disk - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #3266: SSL broken pipes kill the machine and fill the disk
Date
Msg-id 200705171614.l4HGE8B17487@momjian.us
Whole thread Raw
In response to BUG #3266: SSL broken pipes kill the machine and fill the disk  ("Peter Koczan" <pjkoczan@gmail.com>)
Responses Re: BUG #3266: SSL broken pipes kill the machine and fill the disk  (Magnus Hagander <magnus@hagander.net>)
List pgsql-bugs
I didn't see any comment on this.  Seems like a problem.

---------------------------------------------------------------------------

Peter Koczan wrote:
>
> The following bug has been logged online:
>
> Bug reference:      3266
> Logged by:          Peter Koczan
> Email address:      pjkoczan@gmail.com
> PostgreSQL version: 8.2.4
> Operating system:   CentOS Linux 4.4 (RHEL 4) running on Pentium 4
> Description:        SSL broken pipes kill the machine and fill the disk
> Details:
>
> If a connection using SSL is terminated on the client side before a query
> completes, postgres keeps trying to write to the broken connection, shooting
> CPU and load very high and filling the postgres syslog (I have that pointed
> to /var/log/pglog) with ~2000 of the following messages per second.
>
> May 10 14:45:01 mitchell postgres[10340]: [15729-1] LOG:  SSL SYSCALL error:
> Broken pipe
>
> This quickly fills up the /var partition on the server.
>
> To replicate the problem:
> 1. Connect to an running server using an SSL connection. Using psql is
> fine.
> 2. Begin a query on any table. For full effect the query should be expensive
> and large.
> 3. Kill psql *on the client side* BEFORE the query finishes (don't do
> anything to the server side connection).
> 4. 'tail -f' wherever the postgres server output and error is going to.
> 5. Wait a few seconds while the server gets all of its data.
> 6. See thousands of error messages fill up your terminal on the server.
>
> This has also happened when people stop web browsers in the middle of
> serving up a postgresql-driven web page, but this is harder to replicate.
>
> This usually terminates, but after 3 hours for a query that usually takes 20
> seconds. During this time, the server is slow to the point of unusable.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: strange problem with ip6
Next
From: Stephan Szabo
Date:
Subject: Re: ON DELETE CASCADE with multiple paths