| 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-27 10:48:30 |
| Message-ID: | 372595FE.2F6BAC2D@krs.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hiroshi Inoue wrote:
>
> Now I'm suspicious about the following code in LockResolveConflicts().
>
> /*
> * We can control runtime this option. Default is lockReadPriority=0
> */
> if (!lockReadPriority)
> {
> /* ------------------------
> * If someone with a greater priority is waiting for the
> lock,
> * do not continue and share the lock, even if we can. bjm
> * ------------------------
You're right Hiroshi - this must be changed:
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...
Bruce, what do you think?
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vadim Mikheev | 1999-04-27 10:52:41 | Re: [INTERFACES] JDBC and waiting for commit on a locked table in6.4.2 |
| Previous Message | Hiroshi Inoue | 1999-04-27 10:24:07 | RE: [HACKERS] Lock freeze ? in MVCC |