From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Klein <brucek(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: WSL (windows subsystem on linux) users will need to turn fsync off as of 11.2 |
Date: | 2019-02-15 17:06:58 |
Message-ID: | 20190215170658.z5hj7irs6ig4l66r@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
On 2019-02-14 19:48:05 -0500, Tom Lane wrote:
> Bruce Klein <brucek(at)gmail(dot)com> writes:
> > If you are running Postgres inside Microsoft WSL (at least on Ubuntu, maybe
> > on others too), and just picked up a software update to version 11.2, you
> > will need to go into your /etc/postgresql.conf file and set fsync=off.
>
> Hm. Probably this is some unexpected problem with the
> panic-on-fsync-failure change; although that still leaves some things
> unexplained, because if fsync is failing for you now, why didn't it fail
> before? Anyway, you might try experimenting with data_sync_retry,
> instead of running with scissors by turning off fsync altogether.
> See first item in the release notes:
>
> https://www.postgresql.org/docs/11/release-11-2.html
>
> Also, we'd quite like to hear more details; can you find any PANIC
> messages in the server log?
I suspect that's because WSL has an empty implementation of
sync_file_range(), i.e. it unconditionally returns ENOSYS. But as
configure detects it, we still emit calls for it. I guess we ought to
except ENOSYS for the cases where we do panic-on-fsync-failure?
You temporarily can work around it, mostly, by setting
checkpoint_flush_after = 0 and bgwriter_flush_after = 0.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-02-15 17:13:10 | Re: WSL (windows subsystem on linux) users will need to turn fsync off as of 11.2 |
Previous Message | Alvaro Herrera | 2019-02-15 16:36:55 | Re: Size estimation of postgres core files |