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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Neil Padgett <npadgett(at)redhat(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, "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 17:04:11
Message-ID: 200107301704.f6UH4B809947@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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.

I see your point now, that they can't synchronize because they have to
go through the same semaphore and therefore get out of sync. Do they
get out of sync enough for one to get the lock while the other is not
holding it, or do the locks actually keep them in sync? I don't know
the answer.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikheev, Vadim 2001-07-30 17:12:22 RE: Performance TODO items
Previous Message Neil Padgett 2001-07-30 16:57:25 Re: Revised Patch to allow multiple table locks in "Unison"

Browse pgsql-patches by date

  From Date Subject
Next Message Fernando Nasser 2001-07-30 17:24:26 Re: Revised Patch to allow multiple table locks in "Unison"
Previous Message Neil Padgett 2001-07-30 16:57:25 Re: Revised Patch to allow multiple table locks in "Unison"