Skip site navigation (1) Skip section navigation (2)

Re: BUG #3266: SSL broken pipes kill the machine and fill the disk

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Koczan <pjkoczan(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3266: SSL broken pipes kill the machine and fill the disk
Date: 2007-05-17 16:14:08
Message-ID: 200705171614.l4HGE8B17487@momjian.us (view raw or flat)
Thread:
Lists: 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(at)gmail(dot)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(at)momjian(dot)us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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

In response to

Responses

pgsql-bugs by date

Next:From: Stephan SzaboDate: 2007-05-17 16:15:10
Subject: Re: ON DELETE CASCADE with multiple paths
Previous:From: Tom LaneDate: 2007-05-17 16:01:02
Subject: Re: strange problem with ip6

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group