Re: fdatasync performance problem with large number of DB files

From: Michael Brown <michael(dot)brown(at)discourse(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: fdatasync performance problem with large number of DB files
Date: 2021-02-23 04:25:49
Message-ID: 2feba0d3-28c2-08a6-c398-7ddc415293d2@discourse.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2021-02-22 5:43 p.m., Tom Lane wrote:
> Michael Brown <michael(dot)brown(at)discourse(dot)org> writes:
>> * is there a knob missing we can configure?
>
> No. The trouble with sync() is that per POSIX, it only schedules the
> writes; there's no way to tell when the work has been done. I see
> that Linux offers stronger promises in this department, but I don't
> think that's very portableTrue, but as mentioned below we're looking for a "this makes sense for
our environment" switch.

> Moreover, even on Linux there's no way to detect whether any of the writes failed.
Ugh. Presumably those would be noticed when the WAL replays? (I'll admit
I'd have to look at the sequence of events and think about it, I don't
know offhand.)

Oh, syncfs() exists but is Linux-specific, again, darn.

> Barring some solution to those problems, we would be unlikely to take
> a patch that uses sync() instead of fsync().
I wouldn't dare to propose outright switching to sync() for everyone,
but a knob we can turn on to say "use sync (or syncfd()) instead" is
what we need, discounting a better solution.

--
Michael Brown
Civilized Discourse Construction Kit, Inc.
https://www.discourse.org/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2021-02-23 05:23:02 Re: pg_restore - generated column - not populating
Previous Message Santosh Udupi 2021-02-23 03:43:36 Re: pg_restore - generated column - not populating