Re: Two fsync related performance issues?

From: Paul Guo <pguo(at)pivotal(dot)io>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Two fsync related performance issues?
Date: 2020-05-18 15:12:32
Message-ID: CAEET0ZERL+UGw9aG6zh=yF7tcnVB5g1UbFE8+v9DvVwhwTgo9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the replies.

On Tue, May 12, 2020 at 2:04 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Tue, May 12, 2020 at 12:55:37PM +0900, Fujii Masao wrote:
> > On 2020/05/12 9:42, Paul Guo wrote:
> >> 1. StartupXLOG() does fsync on the whole data directory early in
> >> the crash recovery. I'm wondering if we could skip some
> >> directories (at least the pg_log/, table directories) since wal,
> >> etc could ensure consistency.
> >
> > I agree that we can skip log directory but I'm not sure if skipping
> > table directory is really safe. Also ISTM that we can skip the
> directories
> > that those contents are removed or zeroed during recovery,
> > for example, pg_snapshots, pg_substrans, etc.
>
> Basically excludeDirContents[] as of basebackup.c.
>

table directories & wal fsync probably dominates the fsync time. Do we
know any possible real scenario that requires table directory fsync?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2020-05-18 15:33:07 proposal - plpgsql - FOR over unbound cursor
Previous Message Daniel Gustafsson 2020-05-18 15:04:02 Vintage unused variables in pg_dump.c