Re: [HACKERS] Notice: heap_open/close changes committed
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Notice: heap_open/close changes committed |
Дата | |
Msg-id | 37E6554E.8F4C0F13@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Notice: heap_open/close changes committed (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > > > This is the old bug (pre-6.5.X released WRITE lock just after > > system table was modified). I had no time to fix it and so > > just changed old WRITE lock with new AccessExclusiveLock. > > I do not think changing RowExclusiveLock back to AccessExclusiveLock > will fix it unless we hold the lock till end of transaction, no? Yes. > That seems like much too high a price to pay. That's why I proposed to use Exclusive lock (it doesn't conflict with AccessShareLock used by readers). > > But we have to handle this in proper way (wait if t_xmax > > is id of an active transaction). > > Yes. Where is the code that does this right in the regular executor? > I will see what needs to be done to make the system table accesses > act the same. Sorry - I messed things up: heap_replace/heap_delete wait for concurrent update, but doesn't update/delete modified tuple. They return result code (HeapTupleMayBeUpdated etc in utils/tqual.h) and it's up to caller decide what to do if tuple modified by concurrent transaction. For _updated_ tuple TID of new tuple version is also returned (if requested)... Examples of how this is handled/used by Executor are in execMain.c (just search for HeapTupleUpdated). Vadim
В списке pgsql-hackers по дате отправления: