On Fri, Nov 9, 2012 at 2:50 PM, Eliot Gable
wrote:
>>> one thing that can cause this unfortunately is advisory locks eating
>>> up exactly the amount of shared memory you have. that's another thing
>>> to rule out.
>>
>> How would I rule this out?
>
> It really was filling the locks table.
>
> Us
> Another process comes along and processes records which are being inserted
> into the database. It pulls up to 10 records from a table, processes them,
> and moves those records into a "processed" table. The processing of the
> records is rather complex. To facilitate the processing, 6 temporary
> most likely possibility you have a transaction being left open and
> accumulating locks. of course, you have to rule out the fact that
> you simply have to increase max_locks_per_transaction: if you have a
> lot of tables, it might be reasonable to have to extend this on a
> stock config.
>
>
W
On Fri, Nov 9, 2012 at 8:43 AM, Eliot Gable
wrote:
> I have a PGSQL 9.0.1 database which is on the back-end of an app I was
> stress testing last night. This morning, when I try to run psql, I get:
>
> psql: FATAL: out of shared memory
> HINT: You might need to increase max_locks_per_transaction
