Re: Postgres, fsync, and OSs (specifically linux)
От | Andres Freund |
---|---|
Тема | Re: Postgres, fsync, and OSs (specifically linux) |
Дата | |
Msg-id | 20180517164440.szk6vhbdprcm462a@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Postgres, fsync, and OSs (specifically linux) (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Postgres, fsync, and OSs (specifically linux)
Re: Postgres, fsync, and OSs (specifically linux) |
Список | pgsql-hackers |
Hi, On 2018-05-10 09:50:03 +0800, Craig Ringer wrote: > while ((src = (RewriteMappingFile *) hash_seq_search(&seq_status)) != NULL) > { > if (FileSync(src->vfd, WAIT_EVENT_LOGICAL_REWRITE_SYNC) != 0) > - ereport(ERROR, > + ereport(PANIC, > (errcode_for_file_access(), > errmsg("could not fsync file \"%s\": %m", src->path))); To me this (and the other callers) doesn't quite look right. First, I think we should probably be a bit more restrictive about when PANIC out. It seems like we should PANIC on ENOSPC and EIO, but possibly not others. Secondly, I think we should centralize the error handling. It seems likely that we'll acrue some platform specific workarounds, and I don't want to copy that knowledge everywhere. Also, don't we need the same on close()? - Andres
В списке pgsql-hackers по дате отправления: