Re: autovacuum and locks - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: autovacuum and locks
Date
Msg-id 20071023145753.GA18013@alvh.no-ip.org
Whole thread Raw
In response to autovacuum and locks  ("Dietmar Maurer" <dietmar@maurer-it.com>)
Responses Re: autovacuum and locks  ("Dietmar Maurer" <dietmar@maurer-it.com>)
List 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

pgsql-general by date:

Previous
From: Erik Jones
Date:
Subject: Re: Determine query run-time from pg_* tables
Next
From: Dave Page
Date:
Subject: Re: 8.2.3: Server crashes on Windows using Eclipse/Junit