| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Brown <michael(dot)brown(at)discourse(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fdatasync performance problem with large number of DB files |
| Date: | 2021-03-11 01:32:07 |
| Message-ID: | CA+hUKGLkcJ=9qD69NU0W6SEz-JGzdDtjjF2TedoYKgD2ky=atg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 11, 2021 at 2:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Trolling the net, I found a newer-looking version of the man page,
> and behold it says
>
> In mainline kernel versions prior to 5.8, syncfs() will fail only
> when passed a bad file descriptor (EBADF). Since Linux 5.8,
> syncfs() will also report an error if one or more inodes failed
> to be written back since the last syncfs() call.
>
> So this means that in less-than-bleeding-edge kernels, syncfs can
> only be regarded as a dangerous toy. If we expose an option to use
> it, there had better be large blinking warnings in the docs.
Agreed. Perhaps we could also try to do something programmatic about that.
Its fsync() was also pretty rough for the first 28 years.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2021-03-11 01:34:12 | Re: 64-bit XIDs in deleted nbtree pages |
| Previous Message | Tom Lane | 2021-03-11 01:25:05 | Re: fdatasync performance problem with large number of DB files |