| From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
|---|---|
| To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Lock freeze ? in MVCC |
| Date: | 1999-04-28 11:01:56 |
| Message-ID: | 3726EAA4.FAD4541A@krs.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hiroshi Inoue wrote:
>
> >
> > if we already have some lock with priority X and new requested
> > lock has priority Y, Y <= X, then lock must be granted.
> >
> > Also, I would get rid of lockReadPriority stuff...
> >
>
> I found a problem to get rid of lockReadPriority stuff completely.
> If there's a table which is insert/update/deleted very frequenly by
> several processes,processes which request the high priority lock
> (such as vacuum) could hardly acquire the lock for the table.
I didn't mean to get rid of code checking waiter locks completely.
I just said that condition below
if (!lockReadPriority)
is unuseful any more.
Read my prev letter when, imo, we have to take waiters into
account.
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | The Hermit Hacker | 1999-04-28 12:07:10 | v6.5 Release Date ... |
| Previous Message | Vadim Mikheev | 1999-04-28 10:55:54 | Re: [HACKERS] Lock freeze ? in MVCC |