From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> |
Cc: | "Osborn, Jeff" <jeosborn(at)akamai(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Occasional timeouts on TRUNCATE and simple INSERTs |
Date: | 2012-12-11 22:16:43 |
Message-ID: | CAHyXU0xyuwjCjn288hV9wXyF0-NY+CTnz3R6VVFGWZ5=Lovudg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Dec 11, 2012 at 3:38 PM, Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> wrote:
> On Tue, Dec 11, 2012 at 1:19 PM, Osborn, Jeff <jeosborn(at)akamai(dot)com> wrote:
>> I am seeing some strange performance on a new pg9.1 instance. We are seeing occasional statement timeouts on some TRUNCATEs and INSERTs. In both cases, the statements are quite simple:
>> - TRUNCATE schema.table;
>> - INSERT INTO schema.table VALUES ($1,2,$2,'');
>>
>> Sometimes these will succeed. Occasionally I see timeouts. The statement_timeout is set to 60 seconds. These tables are not particularly large; in the case of the insert, the table only has three rows.
>
> A most common case is when backup (pg_dump*) is running TRUNCATE has
> to wait for it because it acquires an access exclusive lock on a table
> and all other queries including INSERT have to wait for the TRUNCATE.
> Check the backup case first.
Yeah: absolute first thing to check is if your statements are being
blocked -- you can get that via pg_stat_activity from another session.
It's a completely different beast if that's the case.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Osborn, Jeff | 2012-12-11 22:34:16 | Re: Occasional timeouts on TRUNCATE and simple INSERTs |
Previous Message | Sergey Konoplev | 2012-12-11 21:38:38 | Re: Occasional timeouts on TRUNCATE and simple INSERTs |