Re: Refactoring the checkpointer's fsync request queue - Mailing list pgsql-hackers

From Shawn Debnath
Subject Re: Refactoring the checkpointer's fsync request queue
Date
Msg-id 20190213025843.GA52283@f01898859afd.ant.amazon.com
Whole thread Raw
In response to Re: Refactoring the checkpointer's fsync request queue  (Shawn Debnath <sdn@amazon.com>)
Responses Re: Refactoring the checkpointer's fsync request queue  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Wed, Jan 30, 2019 at 09:59:38PM -0800, Shawn Debnath wrote:

> I wonder if it might be better to introduce two different functions 
> catering to the two different use cases for forcing an immediate sync:
> 
> - sync a relation
>     smgrimmedsyncrel(SMgrRelation, ForkNumber)
> - sync a specific segment
>     smgrimmedsyncseg(SMgrRelation, ForkNumber, SegmentNumber)
> 
> This will avoid having to specify InvalidSegmentNumber for majority of 
> the callers today.

I have gone ahead and rebased the refactor patch so it could cleanly 
apply on heapam.c, see patch v7.

I am also attaching a patch (v8) that implements smgrimmedsyncrel() and 
smgrimmedsyncseg() as I mentioned in the previous email. It avoids 
callers to pass in InvalidSegmentNumber when they just want to sync the 
whole relation. As a side effect, I was able to get rid of some extra 
checkpointer.h includes.  

--
Shawn Debnath
Amazon Web Services (AWS)

Attachment

pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Protect syscache from bloating with negative cache entries
Next
From: Simon Riggs
Date:
Subject: Re: monitoring CREATE INDEX [CONCURRENTLY]