Re: Good name for new lock type for VACUUM?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Good name for new lock type for VACUUM?
Date: 2001-06-23 22:26:38
Message-ID: 9021.993335198@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> Still, it's an interesting alternative. Comments anyone?

> SelfExclusiveLock is clear and can't be confused with other lock types.

It could possibly be made a little less dangerous if "SelfExclusiveLock"
were defined to conflict with itself and AccessExclusiveLock (and
nothing else). That would at least mean that holding SelfExclusiveLock
would guarantee the table not go away under you; so there might be
scenarios where holding just that lock would make sense.

Still, I'm not sure that this lock type is as flexible as it seems at
first glance. What you'd probably really want it to do is guarantee
that no other instance of your same operation (whatever it is) is
running, and then you'd acquire another lock type to lock out other
operations that you couldn't run in parallel with. Sounds great,
except there'd only be one SelfExclusiveLock per table. So, for
example, your operation would conflict with VACUUM whether you wanted
it to or not.

Between that and the need-two-locks hazards, I'm unconvinced that this
is a better idea.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut - PostgreSQL 2001-06-23 23:29:48 pgsql/src/bin/initdb initdb.sh
Previous Message mlw 2001-06-23 22:12:46 Working out of the box