Skip site navigation (1) Skip section navigation (2)

Re: Revised Patch to allow multiple table locks in "Unison"

From: Neil Padgett <npadgett(at)redhat(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Neil Padgett <npadgett(at)redhat(dot)com>, "pgsql-patches(at)postgresql(dot)org" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Revised Patch to allow multiple table locks in "Unison"
Date: 2001-07-30 16:57:25
Message-ID: Pine.LNX.4.33.0107301251440.5028-100000@lacrosse.corp.redhat.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Mon, 30 Jul 2001, Bruce Momjian wrote:

> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Actually, with this new code, we could go back to locking in oid order,
> > > which would eliminate the problem.
> >
> > No it wouldn't.  If anything, locking in a *randomized* order would be
> > the best bet.  But I have no confidence in this approach, anyway.
>
> I am looking for a way to get this in there without munging the lock
> code, which is already quite complex.  What about doing some sort of
> small sleep after we reset back to the beginning of the table list.

It seems to me that we already have a small sleep in place. After all, in
order to acquite a lock, the shared memory area has to be accessed. So,
the contenders for a lock both have to go through a spin lock. So, if we
have the two "stuck" processes as in Tom's example, one will win at
acquiring the spin lock and the other will have to wait. So, they become
desynchronized, regardless of how many CPUs or what memory architecture
you have.

Neil

-- 
Neil Padgett
Red Hat Canada Ltd.                       E-Mail:  npadgett(at)redhat(dot)com
2323 Yonge Street, Suite #300,
Toronto, ON  M4P 2C9



In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-07-30 17:04:11
Subject: Re: Revised Patch to allow multiple table locks in "Unison"
Previous:From: Bruce MomjianDate: 2001-07-30 16:55:38
Subject: Re: Revised Patch to allow multiple table locks in "Unison"

pgsql-patches by date

Next:From: Bruce MomjianDate: 2001-07-30 17:04:11
Subject: Re: Revised Patch to allow multiple table locks in "Unison"
Previous:From: Bruce MomjianDate: 2001-07-30 16:55:38
Subject: Re: Revised Patch to allow multiple table locks in "Unison"

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group