Re: Reviewing freeze map code

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Reviewing freeze map code
Дата
Msg-id CAA4eK1+19nb50V1tGRj93pvTK=pf9F0Xcp-xam9GsMwO4HuugQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Reviewing freeze map code  (Andres Freund <andres@anarazel.de>)
Ответы Re: Reviewing freeze map code  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Thu, Jun 30, 2016 at 9:13 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-06-30 08:59:16 +0530, Amit Kapila wrote:
>> On Wed, Jun 29, 2016 at 10:30 PM, Andres Freund <andres@anarazel.de> wrote:
>> > On 2016-06-29 19:04:31 +0530, Amit Kapila wrote:
>> >> There is nothing in this record which recorded the information about
>> >> visibility clear flag.
>> >
>> > I think we can actually defer the clearing to the lock release?
>>
>> How about the case if after we release the lock on page, the heap page
>> gets flushed, but not vm and then server crashes?
>
> In the released branches there's no need to clear all visible at that
> point. Note how heap_lock_tuple doesn't clear it at all. So we should be
> fine there, and that's the part where reusing an existing record is
> important (for compatibility).
>

For back branches, I agree that heap_lock_tuple is sufficient, but in
that case we should not clear the vm or page bit at all as done in
proposed patch.

> But your question made me realize that we despearately *do* need to
> clear the frozen bit in heap_lock_tuple in 9.6...
>

Right.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gavin Flower
Дата:
Сообщение: Re: 10.0
Следующее
От: Sachin Kotwal
Дата:
Сообщение: Re: pgbench unable to scale beyond 100 concurrent connections