Re: total db lockup

From: <eugene1(at)sympatico(dot)ca>
To: <pgsql-general(at)postgresql(dot)org>
Subject: Re: total db lockup
Date: 2005-08-18 17:06:54
Message-ID: 20050818170654.YVZX1586.tomts42-srv.bellnexxia.net@[209.226.175.82]
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

So can anyone offer any insight on this? BTW, I tried reposting it with attachments and it didn't show up.

thanks,

Eugene

>
> From: <eugene1(at)sympatico(dot)ca>
> Date: 2005/08/18 Thu AM 09:24:30 EST
> To: <pgsql-general(at)postgresql(dot)org>
> Subject: [GENERAL] total db lockup
>
> (NOTE: reposting this for the *fifth* time because my previous messages didn't go through).
>
>
> Hi all,
>
> We have experienced a really weird problem with
> postgresql yesterday. When I was called in to take a
> look, all the non-superuser connections were used up
> and they were all in a waiting state (SELECT waiting,
> UPDATE waiting, etc.). I couldn't figure out what the
> problem is, but I saved the ps, pg_stat_activity, and
> pg_locks state at the time (attached as
> condor_db_stats.txt). BTW, when looking at the queries
> in pg_stat_activity, postgresql cuts them off so you
> can't see the entire string. Is there any way to
> prevent that, or at least increase the character
> limit?
>
> We restarted postgresql server and the problem
> reappeared a few minutes later. I saved that state
> also (condor_db_stats2.txt). At that point, after we
> restarted postgresql (again), I ran VACUUM on the
> entire database and did a few more things that seem to
> have solved the problem (see below).
>
> This particular database is essentially just one flat
> table (level) with a few small supporting tables. Only
> the level table is heavily used. (table definition is
> attached as table.txt). I noticed that one of the
> indexes (level_owner_index) was a hash index. I
> remembered what postgresql manual says about hash
> indexes and concurrency
> (http://www.postgresql.org/docs/7.4/interactive/locking-indexes.html)
> and, after VACUUM finished, replaced the hash index
> with a btree. I then did a REINDEX of the level table
> and ANALYZE. This seems to have solved the problem --
> at least as of this morning we still have not seen any
> deadlocks.
>
> My question is, what could have caused this to happen?
> Can anyone explain this paragraph from the manual:
>
> "Share/exclusive page-level locks are used for
> read/write access. Locks are released after the page
> is processed. Page-level locks provide better
> concurrency than index-level ones but are liable to
> deadlocks."
>
>
> Any other pointers to help me figure out what went
> wrong and how to fix it?
>
> thanks,
>
> Eugene
>
> WTF? My message doesn't appear. Trying again without
> attachments or inline text.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

Responses

Browse pgsql-general by date

  From Date Subject
Next Message eugene1 2005-08-18 17:16:55 Re: Same database, different query plans
Previous Message Bruno Wolff III 2005-08-18 17:05:10 Re: Startup ...