From: Simon Riggs <simon@2ndquadrant.com>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Carlo Stonebanks <stonec.register@sympatico.ca>
Cc: pgsql-performance@postgresql.org
Subject: Re: commit so slow program looks frozen
Date: Sat, 28 Oct 2006 11:07:02 +0100
Message-ID: <1162030022.11568.168.camel@silverbirch.site> (raw)
In-Reply-To: <b42b73150610260806le117c55s126585ca6421cb0f@mail.gmail.com>
References: <6E0907A94904D94B99D7F387E08C4F570192F2D0@FALCON.INSIGHT>
<ehqhpe$20jt$1@news.hub.org>
<b42b73150610260806le117c55s126585ca6421cb0f@mail.gmail.com>
On Thu, 2006-10-26 at 11:06 -0400, Merlin Moncure wrote:
> On 10/26/06, Carlo Stonebanks <stonec.register@sympatico.ca> wrote:
> > This is pretty interesting - where can I read more on this? Windows isn't
> > actually hanging, one single command line window is - from its behaviour, it
> > looks like the TCL postgresql package is waiting for pg_exec to come back
> > from the commit (I believe the commit has actually gone through).
> >
> > It could even be that there's something wrong with the TCL package, but from
> > my understanding it is one of the most complete interfaces out there - which
> > is weird, because TCL seems to be the most unpopular language in the
> > community.
>
> when it happens, make sure to query pg_locks and see what is going on
> there lock issues are not supposed to manifest on a commit, which
> releases locks, but you never know. There have been reports of
> insonsistent lock ups on windows (espeically multi-processor) which
> you might be experiencing. Make sure you have the very latest version
> of pg 8.1.x. Also consider checking out 8.2 and see if you can
> reproduce the behavior there...this will require compiling postgresql.
Merlin,
Rumour has it you managed to get a BT from Windows. That sounds like it
would be very useful here.
Carlo,
Many things can happen at commit time. Temp tables dropped, TRUNCATEd
old relations unlinked, init files removed, deferred foreign key checks
(and subsequent cascading), dropped tables flushed. The assumption that
COMMIT is a short request may not be correct according to the wide range
of tasks that could occur according to standard SQL:2003 behaviour.
Some of those effects take longer on larger systems. Any and all of
those things have potential secondary effects, all of which can also
conflict with other user tasks and especially with a CHECKPOINT. Then
there's various forms of contention caused by misconfiguration.
I do think we need some better instrumentation for this kind of thing.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: simon@2ndquadrant.com, mmoncure@gmail.com, stonec.register@sympatico.ca
Subject: Re: commit so slow program looks frozen
In-Reply-To: <1162030022.11568.168.camel@silverbirch.site>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox