| From: | Joseph Shraibman <jks(at)selectacast(dot)net> | 
|---|---|
| To: | srn(at)commsecure(dot)com(dot)au | 
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: postgres deadlocks | 
| Date: | 2001-07-25 22:32:48 | 
| Message-ID: | 3B5F4910.FCCC062D@selectacast.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
Stephen Robert Norris wrote:
> 
> On Wed, Jul 25, 2001 at 05:38:06PM -0400, Joseph Shraibman wrote:
> > My postgres deadlocked again today.  Logs indicated that before the
> > nightly vacuum -z everything was fine, but after it was locked.  The
> > postgres.log contained the end of the vacuum which appeared to be
> > consistant with the other vacuums in the log.  A ps showed no vacuuming
> > processes, but it did show one 'idle in transaction'.  This problem last
> > happened in Februrary when I was using 7.0.3.
> >
> >  select version();
> >                                version
> > ---------------------------------------------------------------------
> >  PostgreSQL 7.1.2 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
> > (1 row)
> >
> >
> > [root(at)p1 /var/log] ps ax | grep postgres
> > 16973 ?        S      0:36 postgres: user2 owl 127.0.0.1 idle
> > 17105 ?        S      0:01 postgres: user2 owl 127.0.0.1 idle
> > 17122 ?        S      1:51 postgres: user2 owl 127.0.0.1 idle
> > 17302 ?        S      1:19 postgres: user2 owl 127.0.0.1 UPDATE waiting
> > 17453 ?        S      0:32 postgres: user2 owl 127.0.0.1 idle
> > 18202 ?        S      0:03 postgres: user2 owl 127.0.0.1 idle
> > 18351 ?        S      0:12 postgres: user2 owl 127.0.0.1 idle in
> > transaction
> > 18352 ?        S      0:00 postgres: user2 owl 127.0.0.1 idle
> >  7137 ?        S      0:00 postgres: user2 owl 127.0.0.1 idle
> >
> 
> Whenever I've seen something like this it's turned out to be a deadlock
> between the process in the transaction and the transaction (UPDATE in this
> case) waiting.
> 
> I think it's generally bad for a client to be idle in a transaction?
> 
Not generally.  I program could do a SELECT FOR UPDATE, do some
processing, do an UPDATE, and then do an END, but my program wasn't
doing that (as far as I can tell, and I've been looking very closely).
But *something* got idle in trasaction.
Even more fustrating it seemed that my whole database was locked, not
just one table, and what could have locked the whole thing except
vacuum?
-- 
Joseph Shraibman
jks(at)selectacast(dot)net
Increase signal to noise ratio.  http://www.targabot.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Wolfe | 2001-07-25 22:44:44 | Re: Hardware Recommendations | 
| Previous Message | Stephen Robert Norris | 2001-07-25 22:19:13 | Re: postgres deadlocks |