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