Re: Postgres crash? could not write to log file: No space left on device
От | Heikki Linnakangas |
---|---|
Тема | Re: Postgres crash? could not write to log file: No space left on device |
Дата | |
Msg-id | 51D29AA0.3070509@vmware.com обсуждение исходный текст |
Ответ на | Re: Postgres crash? could not write to log file: No space left on device (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On 26.06.2013 17:15, Tom Lane wrote: > Heikki Linnakangas<hlinnakangas@vmware.com> writes: >> We've discussed retrying short writes before, and IIRC Tom has argued >> that it shouldn't be necessary when writing to disk. Nevertheless, I >> think we should retry in XLogWrite(). It can write much bigger chunks >> than most write() calls, so there's more room for a short write to >> happen there if it can happen at all. Secondly, it PANICs on failure, so >> it would be nice to try a bit harder to avoid that. > > Seems reasonable. My concern about the idea in general was the > impossibility of being sure we'd protected every single write() call. > But if we can identify specific call sites that seem at more risk than > most, I'm okay with adding extra logic there. Committed a patch to add retry loop to XLogWrite(). I noticed that FileWrite() has some additional Windows-specific code to also retry on an ERROR_NO_SYSTEM_RESOURCES error. That's a bit scary, because we don't check for that in any other write() calls in the backend. If we really need to be prepared for that on Windows, I think that would need to be in a wrapper function in src/port or src/backend/port. Would a Windows-person like to comment on that? - Heikki
В списке pgsql-bugs по дате отправления: