Re: [HACKERS] Notice: heap_open/close changes committed
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Notice: heap_open/close changes committed |
Дата | |
Msg-id | 13572.937836039@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Notice: heap_open/close changes committed (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
Vadim Mikheev <vadim@krs.ru> writes: > Tom Lane wrote: >> 2. I made most opens of system relations grab AccessShareLock if >> read-only, or RowExclusiveLock if read-write, on the theory that > ^^^^^^^^^^^^^^^^ > There are problems here. In the case of normal UPDATE/DELETE > (when RowExclusiveLock is acquired) Executor takes care about > the-same-row writers, but other parts of system don't check > is tuple read being updated concurrent transaction or not. Drat. I was afraid I might be getting in over my head :-( > 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? That seems like much too high a price to pay. > 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. regards, tom lane
В списке pgsql-hackers по дате отправления: