Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Reviewing freeze map code
Date
Msg-id CAD21AoBKZbdhnxxSL41ZBcJSqCr7S9=ZnNcwR=w+qwvTNJp3oQ@mail.gmail.com
Whole thread Raw
In response to Re: Reviewing freeze map code  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Reviewing freeze map code  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Sat, Jul 2, 2016 at 12:34 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Jul 1, 2016 at 7:52 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> On Fri, Jul 1, 2016 at 11:12 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>>
>>> Why do you think IndexOnlyScan will return wrong result?  If the
>>> server crash in the way as you described, the transaction that has
>>> made modifications will anyway be considered aborted, so the result of
>>> IndexOnlyScan should not be wrong.
>>>
>>
>> Ah, you're right, I misunderstood.
>>
>> Attached updated patch incorporating your comments.
>> I've changed it so that heap_xlog_lock clears vm flags if page is
>> marked all frozen.
>>
>
> I think we should make a similar change in heap_lock_tuple API as
> well.
> Also, currently by default heap_xlog_lock tuple tries to clear
> the visibility flags, isn't it better to handle it as we do at all
> other places (ex. see log_heap_update), by logging the information
> about same.

I will deal with them.

> Though, it is important to get the patch right, but I feel in the
> meantime, it might be better to start benchmarking.  AFAIU, even if
> change some part of information while WAL logging it, the benchmark
> results won't be much different.

Okay, I will do the benchmark test as well.

Regards,

--
Masahiko Sawada



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [CF2016-9] Allow spaces in working path on tap-tests
Next
From: Masahiko Sawada
Date:
Subject: Re: Reviewing freeze map code