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 |
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 |