On Sat, Mar 3, 2018 at 3:26 AM, Tom Lane wrote:
> Alexander Kuzmenkov writes:
>> Looks like a leak indeed, the fix seems right.
>
>
> Hence, I propose the attached patch. The test lobotomization
> (the "if (1) //" change) isn't meant for commit but shows how I tested
> the take-the-pin paths. T
Alexander Kuzmenkov writes:
> Looks like a leak indeed, the fix seems right.
Yup, it's a leak. It's hard to hit because you need to be starting
with an update of a tuple in an all-visible page; otherwise we never
pin the vm page so there's nothing to leak. But if you lobotomize
the test a few l
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Looks like a leak indeed, the fix seems right.
On Tue, Feb 13, 2018 at 10:11 AM, Amit Kapila 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:
>
> he
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(BufferGetP
