Re: Checkpoint not retrying failed fsync?

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Checkpoint not retrying failed fsync?
Дата
Msg-id CAA4eK1KHXazjeb+Tyq+3UDHyNpMU7qL3FzYjLEzN-ZQ678L5pw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Checkpoint not retrying failed fsync?  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: Checkpoint not retrying failed fsync?  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Fri, Apr 6, 2018 at 6:26 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Fri, Apr 6, 2018 at 11:36 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> On Fri, Apr 6, 2018 at 11:34 AM, Andrew Gierth
>> <andrew@tao11.riddles.org.uk> wrote:
>>> Right.
>>>
>>> But I don't think just copying the value is sufficient; if a new bit was
>>> set while we were processing the old ones, how would we know which to
>>> clear? We couldn't just clear all the bits afterwards because then we
>>> might lose a request.
>>
>> Agreed.  The attached draft patch handles that correctly, I think.
>
> After some testing, here is a better one for review.  Changes:
>
> 1.  The copy wasn't really needed.
> 2.  errno needed to be restored (in case bms_union stomped on it),
> thanks to Andrew for an off-list complaint about that.
> 3.  Memory context was wrong.
> 4.  bms_first_member() eats its input.  Need to use bms_next_member() instead.
>

Won't in the success case, you need to delete each member (by
something like bms_del_member) rather than just using bms_free?

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


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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: lazy detoasting
Следующее
От: Arseny Sher
Дата:
Сообщение: Fix slot's xmin advancement and subxact's lost snapshots in decoding.