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

From Melanie Plageman
Subject Re: why do hash index builds use smgrextend() for new splitpoint pages
Date
Msg-id CAAKRu_bPc81M121pOEU7W=+wSWEebiLnrie4NpaFC+kWATFtSA@mail.gmail.com
Whole thread Raw
In response to Re: why do hash index builds use smgrextend() for new splitpoint pages  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: why do hash index builds use smgrextend() for new splitpoint pages  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Fri, Feb 25, 2022 at 11:17 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.

and could it happen that during smgrextend() for the last page, a
checkpoint starts and finishes between FileWrite() and
register_dirty_segment(), then index build finishes, and then a crash
occurs before another checkpoint completes the pending fsync for that
last page?



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Document ordering guarantees on INSERT/UPDATE RETURNING clause
Next
From: Nathan Bossart
Date:
Subject: Re: Allow async standbys wait for sync replication (was: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers)