Re: Postgres, fsync, and OSs (specifically linux)
От | Dmitry Dolgov |
---|---|
Тема | Re: Postgres, fsync, and OSs (specifically linux) |
Дата | |
Msg-id | CA+q6zcUKr9vq5kY1E-G-G70stn0BB4NuJhuOhnMq+6=6B-bfeg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Postgres, fsync, and OSs (specifically linux) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Postgres, fsync, and OSs (specifically linux)
|
Список | 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?
В списке pgsql-hackers по дате отправления: