Re: Unlogged relation copy is not fsync'd

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unlogged relation copy is not fsync'd
Date: 2023-09-07 04:36:30
Message-ID: ZPlTTsQRMTdYYxHg@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 05, 2023 at 02:20:18PM -0400, Robert Haas wrote:
> The general rule throughout the system is that the init-fork of an
> unlogged relation is treated the same as a permanent relation: it is
> WAL-logged and fsyncd. But the other forks of an unlogged relation are
> neither WAL-logged nor fsync'd ... except in the case of a clean
> shutdown, when we fsync even that data.
>
> In other words, somehow it feels like we ought to be trying to defer
> the fsync here until a clean shutdown actually occurs, instead of
> performing it immediately. Admittedly, the bookkeeping seems like a
> problem, so maybe this is the best we can do, but it's clearly worse
> than what we do in other cases.

That's where we usually rely more on RegisterSyncRequest() and
register_dirty_segment() so as the flush of the dirty segments can
happen when they should, but we don't go through the shared buffers
when copying all the forks of a relation file across tablespaces..
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2023-09-07 04:43:09 Re: persist logical slots to disk during shutdown checkpoint
Previous Message Michael Paquier 2023-09-07 04:28:46 Re: pg_basebackup: Always return valid temporary slot names