Re: why do hash index builds use smgrextend() for new splitpoint pages - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: why do hash index builds use smgrextend() for new splitpoint pages
Date
Msg-id CAA4eK1KN1kozZFu7_A_3oT-ypx-2mP8BcNfKdv7kjv1-6u=6iw@mail.gmail.com
Whole thread Raw
In response to Re: why do hash index builds use smgrextend() for new splitpoint pages  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: why do hash index builds use smgrextend() for new splitpoint pages
List pgsql-hackers
On Sat, Feb 26, 2022 at 3:01 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> Since _hash_alloc_buckets() WAL-logs the last page of the
> splitpoint, is it safe to skip the smgrimmedsync()? What if the last
> page of the splitpoint doesn't end up having any tuples added to it
> during the index build and the redo pointer is moved past the WAL for
> this page and then later there is a crash sometime before this page
> makes it to permanent storage. Does it matter that this page is lost? If
> not, then why bother WAL-logging it?
>

I think we don't care if the page is lost before we update the
meta-page in the caller because we will try to reallocate in that
case. But we do care after meta page update (having the updated
information about this extension via different masks) in which case we
won't lose this last page because it would have registered the sync
request for it via sgmrextend before meta page update.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint?
Next
From: Amit Kapila
Date:
Subject: Re: Fix typo in logicalfuncs.c - :%s/private date/Private data