Re: heap_lock_updated_tuple_rec can leak a buffer refcount
От | Amit Kapila |
---|---|
Тема | Re: heap_lock_updated_tuple_rec can leak a buffer refcount |
Дата | |
Msg-id | CAA4eK1JWcdot-vg580G-SVO7vvkVK9xSZAN8fsXoD-zgcrapjw@mail.gmail.com обсуждение исходный текст |
Ответ на | heap_lock_updated_tuple_rec can leak a buffer refcount (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: heap_lock_updated_tuple_rec can leak a buffer refcount
|
Список | pgsql-hackers |
On Tue, Feb 13, 2018 at 10:11 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > It seems to me that heap_lock_updated_tuple_rec can lead to a buffer > refcount leak while locking an updated tuple by an aborted > transaction. In commit - 5c609a74, we have added the code to deal > with aborted transactions as below: > > heap_lock_updated_tuple_rec() > { > .. > > if (PageIsAllVisible(BufferGetPage(buf))) > visibilitymap_pin(rel, block, &vmbuffer); > else > vmbuffer = InvalidBuffer; > > LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE); > .. > -------------------------- below code is added by commit -5c609a74 ----------- > if (TransactionIdDidAbort(HeapTupleHeaderGetXmin(mytup.t_data))) > { > UnlockReleaseBuffer(buf); > return HeapTupleMayBeUpdated; > } > ------------------------------------------------------------- > > I think the above code forgets to deal with vmbuffer and can lead to a > leak of the same. Attached patch ensures that it deals with vmbuffer > when required. > Registered the patch for next CF: https://commitfest.postgresql.org/17/1531/ -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: