Re: WSL (windows subsystem on linux) users will need to turn fsync off as of 11.2

From: Bruce Klein <brucek(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 01:19:39
Message-ID: CA+mCpeg7Pzc75Rg9n9pka3duP0-MG4qMaDgX2Kb7OY=awCZOOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks Tom I feel like I'm in a little over my head here but I'll try to
help as I can.

With fsync off, everything appears to run as it did before on 11.1.

With fsync default/on, the problem is easily reproducible by trying to
create a database. I believe the very first time I saw it it was with a
routine query but I'm not 100% sure.

psql-11.2=> create database testdb;
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
SSL SYSCALL error: EOF detected
The connection to the server was lost. Attempting reset: Failed.
!>

Here are the entries from the log:
1527 2019-02-14 15:06:08.218 DST [8398] PANIC: could not flush dirty data:
Function not implemented
1528 2019-02-14 15:06:08.218 DST [8396] LOG: checkpointer process (PID
8398) was terminated by signal 6: Aborted
1529 2019-02-14 15:06:08.218 DST [8396] LOG: terminating any other active
server processes
1530 2019-02-14 15:06:08.218 DST [8422] homestead(at)homestead WARNING:
terminating connection because of crash of another server process
1531 2019-02-14 15:06:08.218 DST [8422] homestead(at)homestead DETAIL: The
postmaster has commanded this server process to roll back the current
transaction an d exit, because another server process exited abnormally
and possibly corrupted shared memory.
1532 2019-02-14 15:06:08.218 DST [8422] homestead(at)homestead HINT: In a
moment you should be able to reconnect to the database and repeat your
command.
1533 2019-02-14 15:06:08.218 DST [8401] WARNING: terminating connection
because of crash of another server process
1534 2019-02-14 15:06:08.218 DST [8401] DETAIL: The postmaster has
commanded this server process to roll back the current transaction and
exit, because anot her server process exited abnormally and possibly
corrupted shared memory.
1535 2019-02-14 15:06:08.218 DST [8401] HINT: In a moment you should be
able to reconnect to the database and repeat your command.
1536 2019-02-14 15:06:08.241 DST [8396] LOG: all server processes
terminated; reinitializing
1537 2019-02-14 15:06:08.259 DST [8433] LOG: database system was
interrupted; last known up at 2019-02-14 15:05:30 DST
1538 2019-02-14 15:06:08.259 DST [8433] PANIC: could not flush dirty data:
Function not implemented
1539 2019-02-14 15:06:08.264 DST [8396] LOG: startup process (PID 8433)
was terminated by signal 6: Aborted
1540 2019-02-14 15:06:08.264 DST [8396] LOG: aborting startup due to
startup process failure
1541 2019-02-14 15:06:08.266 DST [8434] homestead(at)homestead FATAL: the
database system is in recovery mode
1542 2019-02-14 15:06:08.268 DST [8396] LOG: database system is shut down

As to why it worked before, I don't think fsync() ever worked on WSL, and
there were places where you'd see warnings about it in 11.1, they just
wouldn't crash the server.

As to the "running with scissors" risk, I'm going to guess the most common
use case for WSL is as a personal dev box where all the data is disposable
anyway. That's the case for me at least.

Best,
Bruce

On Thu, Feb 14, 2019 at 2:48 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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?
>
> regards, tom lane
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Klein 2019-02-15 01:55:33 Re: WSL (windows subsystem on linux) users will need to turn fsync off as of 11.2
Previous Message Tom Lane 2019-02-15 00:48:05 Re: WSL (windows subsystem on linux) users will need to turn fsync off as of 11.2