Re: Postgres, fsync, and OSs (specifically linux)
Dmitry Dolgov <9erthalion6@gmail.com>
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>,
Craig Ringer <craig@2ndquadrant.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-05-22T15:37:28Z
Lists: pgsql-hackers
> On 22 May 2018 at 03:08, Andres Freund <andres@anarazel.de> wrote:
> On 2018-05-19 18:12:52 +1200, Thomas Munro wrote:
>> On Sat, May 19, 2018 at 4:51 PM, Thomas Munro
>> <thomas.munro@enterprisedb.com> wrote:
>> > Next, make check hangs in initdb on both of my pet OSes when md.c
>> > raises an error (fseek fails) and we raise and error while raising and
>> > error and deadlock against ourselves. Backtrace here:
>> > https://paste.debian.net/1025336/
>>
>> Ah, I see now that something similar is happening on Linux too, so I
>> guess you already knew this.
>
> I didn't. I cleaned something up and only tested installcheck
> after... Singleuser mode was broken.
>
> Attached is a new version.
>
> I've changed my previous attempt at using transient files to using File
> type files, but unliked from the LRU so that they're kept open. Not sure
> if that's perfect, but seems cleaner.
Thanks for the patch. Out of curiosity I tried to play with it a bit.
`pgbench -i -s 100` actually hang on my machine, because the
copy process ended up with waiting after `pg_uds_send_with_fd`
had
errno == EWOULDBLOCK || errno == EAGAIN
as well as the checkpointer process. Looks like with the default
configuration and `max_wal_size=1GB` it writes more than reads to a
socket, and a buffer eventually becomes full. I've increased
SO_RCVBUF/SO_SNDBUF and `max_wal_size` independently to
check it, and in both cases the problem disappeared (but I assume
only for this particular scale). Is it something that was already considered?
Commits
-
PANIC on fsync() failure.
- 9ccdd7f66e33 12.0 landed
- f1ff5f51d249 9.4.21 landed
- 312435232217 9.5.16 landed
- b9cce9ddfa17 9.6.12 landed
- afbe03f65470 10.7 landed
- 6534d544cd77 11.2 landed
-
Fix and improve pg_atomic_flag fallback implementation.
- 8c3debbbf618 11.0 cited