Re: [HACKERS] FOR SHARE LOCK clause ?

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: vadim(at)krs(dot)ru (Vadim Mikheev)
Cc: lockhart(at)alumni(dot)caltech(dot)edu, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] FOR SHARE LOCK clause ?
Date: 1999-01-06 04:45:35
Message-ID: 199901060445.XAA24402@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > So you are going to shared lock every row. And if a user does a
> > sequential scan of the entire table using SELECT FOR SHARE LOCK, he
> > shared locks every row. Isn't he going to run out of locks?
>
> I would like to work with this issue after 6.5 and writes
> some notes about FOR SHARE LOCK limitations/problems.

OK, just checking. You can't use the xid, so I see the problem with
shared-locking. No way to know which rows were seen by SELECT, so no
way to shared-lock them without an explicit lock.

With Informix, UPDATE automatically locks every row, and you quickly run
out of locks. You have to explicitly lock the table in EXCLUSIVE MODE
in a transaction to prevent your UPDATE from running out of locks on a
large transaction. And you can still run out of log space or generate a
'large transaction' errror because the log got full before the
transaction finished. With MVCC, these are not problems, and FOR SHARED
LOCK is just a special thing people can enable for special cases.

--
Bruce Momjian | http://www.op.net/~candle
maillist(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

Browse pgsql-hackers by date

  From Date Subject
Next Message Clark Evans 1999-01-06 06:49:00 Re: [HACKERS] FOR SHARE LOCK clause ?
Previous Message Vadim Mikheev 1999-01-06 04:40:53 Re: [HACKERS] FOR SHARE LOCK clause ?