Re: Revised Patch to allow multiple table locks in "Unison"
От | Hiroshi Inoue |
---|---|
Тема | Re: Revised Patch to allow multiple table locks in "Unison" |
Дата | |
Msg-id | 3B64D85D.E8633CB9@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: Revised Patch to allow multiple table locks in "Unison" (Neil Padgett <npadgett@redhat.com>) |
Список | pgsql-patches |
Neil Padgett wrote: > > On Mon, 30 Jul 2001, Hiroshi Inoue wrote: > > > I have a question. > > What will happen when the second table is locked for a long time > > though the first table isn't locked ? > > Consider the case: > > LOCK a,b; > > Assume a is free (i.e. not locked), but b is busy (i.e. locked). > > First the system will do a blocking lock attempt on a, which will return > immediately, since a was free. Table a is now locked. Now, the system will > try a non-blocking lock on b. But, b is busy so the lock attempt will fail > immediately (since the lock attempt was non-blocking). So, the system will > back off, and the lock on a is released. > > Next, a blocking lock attempt will be made on b. (Since it was busy last > time, we want to wait for it to become free.) The lock call will block > until b becomes free. At that time, the lock attempt will return, and b > will be locked. Then, a non-blocking lock attempt will be made on table a. Is it paranoid to worry about the followings ? 1) Concurrent 'lock table a, b;' and 'lock table b, a;' could last forever in theory ? 2) 'Lock table a,b' could hardly acquire the lock when both the table a and b are very frequently accessed. regards, Hiroshi Inoue
В списке pgsql-patches по дате отправления: