Re: Refactoring the checkpointer's fsync request queue

From: Shawn Debnath <sdn(at)amazon(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Refactoring the checkpointer's fsync request queue
Date: 2019-02-13 02:58:43
Message-ID: 20190213025843.GA52283@f01898859afd.ant.amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
0002-Refactor-the-fsync-machinery-to-support-future-SM-v7.patch text/plain 81.9 KB
0002-Refactor-the-fsync-machinery-to-support-future-SM-v8.patch text/plain 81.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2019-02-13 02:59:27 Re: monitoring CREATE INDEX [CONCURRENTLY]
Previous Message Tsunakawa, Takayuki 2019-02-13 02:15:42 RE: Protect syscache from bloating with negative cache entries