Re: Reviewing freeze map code
От | Masahiko Sawada |
---|---|
Тема | Re: Reviewing freeze map code |
Дата | |
Msg-id | CAD21AoBKZbdhnxxSL41ZBcJSqCr7S9=ZnNcwR=w+qwvTNJp3oQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reviewing freeze map code (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Reviewing freeze map code
|
Список | 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 по дате отправления: