Re: Reducing some DDL Locks to ShareLock
От | Simon Riggs |
---|---|
Тема | Re: Reducing some DDL Locks to ShareLock |
Дата | |
Msg-id | 1226500339.27904.345.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Reducing some DDL Locks to ShareLock (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Reducing some DDL Locks to ShareLock
|
Список | pgsql-hackers |
On Tue, 2008-11-11 at 21:57 -0500, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Mon, 2008-11-10 at 19:15 -0500, Tom Lane wrote: > >> The reason I was thinking about heap_lock_tuple is that it might provide > >> a suitable defense against that case. > > > OK. Lock tuple works OK, but its the unlock that I'm worried about. How > > would non-transactional un-lock tuple work? > > I was imagining that the heap_inplace_update operation would release the > lock. Is there some problem with the concept? Not the concept, just the mechanism. Current tuple lock requestors do XactLockTableWait() which waits until the lock on the transaction is released and removed from procarray. The only way I can see to do this is by having another lock type, using an additional info bit on t_infomask2. If that is set then we just wait on a tuple lock, rather on the transaction lock. So we would add another wait case into the heap_lock_tuple(), heap_update() and heap_delete(). Maybe NonXactLockTupleWait(). Requirement is to have anybody placing a non-transactional tuple lock to already have a lock on relation. We would not need to WAL log this type of lock, since we will require the lock holder to keep the buffer pinned. The lock type would not need to be replayed for hot standby, That OK, or do you see another way? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: