Re: autovacuum and locks

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Dietmar Maurer <dietmar(at)maurer-it(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: autovacuum and locks
Date: 2007-10-23 14:57:53
Message-ID: 20071023145753.GA18013@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dietmar Maurer wrote:
> > >
> > > Why cant postgres get the RowExclusiveLock in transaction 3369000?
> >
> > Probably because the ExclusiveLock'ers are waiting in front
> > of RowExclusiveLock. Locks are granted in order.
> >
> > It would help if you didn't mangle the pg_locks output so badly.
>
> Yes, sorry about that.
>
> I was able to reproduce the problem, and the problem is that locks are
> granted in order (wonder why?).

Because doing otherwise would cause starvation for some lockers.

> Anyways, i am trying to avoid locks now, by using my own merge
> function to avoid update/insert race condition.
>
> Or what is the suggested way to avoid the update/insert race condition?.

What update/insert race condition? Maybe you are talking about the
subject of example 37-1 here:

http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dietmar Maurer 2007-10-23 15:03:51 Re: autovacuum and locks
Previous Message Erik Jones 2007-10-23 14:28:39 Re: Determine query run-time from pg_* tables