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