Re: WSL (windows subsystem on linux) users will need to turn fsyncoff as of 11.2 - Mailing list pgsql-general
| From | Bruce Klein |
|---|---|
| Subject | Re: WSL (windows subsystem on linux) users will need to turn fsyncoff as of 11.2 |
| Date | |
| Msg-id | CA+mCpeg7Pzc75Rg9n9pka3duP0-MG4qMaDgX2Kb7OY=awCZOOQ@mail.gmail.com Whole thread Raw |
| In response to | Re: WSL (windows subsystem on linux) users will need to turn fsync off as of 11.2 (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | 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@homestead WARNING: terminating connection because of crash of another server process
1531 2019-02-14 15:06:08.218 DST [8422] homestead@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@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@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@sss.pgh.pa.us> wrote:
Bruce Klein <brucek@gmail.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
pgsql-general by date: