title: Can PostgreSQL 9.1 leak locks? (out of shared memory/increase max_pred_locks_per_transaction)
body: <p>We recently upgraded to postgresql 9.1.6 (from 8.3). Our test server indicated that the max_pred_locks_per_transaction should be set at least as high as 900 (which is way beyond the recommended setting of 64).</p>
  
  <p>We're now in production, and I've had to increase this parameter many times, as our log will start filling with:</p>
  
  <pre><code>ERROR:  53200: out of shared memory
  HINT:  You might need to increase max_pred_locks_per_transaction.
  </code></pre>
  
  <p>With a client connection setting of 600 (but a pooling system that never goes over 100 clients):</p>
  
  <p>max_pred_locks_per_transaction:
  We went to 3000. Ran out in about a day.
  Went to 9000, ran out in about 3 days.</p>
  
  <p>I now have it set to 30000, and since this number is the average allocated per allowed client connection, I now have around 5 GB of shared memory dedicated to lock space!</p>
  
  <p>I do have shared_buffers set rather high (24GB at the moment), which is over the 40% RAM figure. (I plan to tune this down to about 25% of RAM at the next restart).</p>
  
  <p><strong>EDIT: This tuning turned out to be a bad idea. My database is it with a lot of heavy queries, and having half of a large RAM dedicated to shared_buffers keeps it from choking, as it can cache the larger tables completely.</strong></p>
  
  <p>On average, I see somewhere around 5-10 active queries at a time. Our query load <em>far</em> outstrips our update load.</p>
  
  <p>Anybody care to tell me how I might track down what is going wrong here? With such a small update set, I really can't figure out why we are running out of locks so often...it really does smell like a leak to me.</p>
  
  <p>Anyone know how to examine where the locks are going? (e.g. how might I read the content of pg_locks with respect to this issue)</p>