Re: Disaster!
От | Tom Lane |
---|---|
Тема | Re: Disaster! |
Дата | |
Msg-id | 3813.1074966763@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Disaster! (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Disaster!
Re: Disaster! |
Список | pgsql-hackers |
I said: > If there wasn't disk space enough to hold the clog page, the checkpoint > attempt should have failed. So it may be that allowing a short read in > slru.c would be patching the symptom of a bug that is really elsewhere. After more staring at the code, I have a theory. SlruPhysicalWritePage and SlruPhysicalReadPage are coded on the assumption that close() can never return any interesting failure. However, it now occurs to me that there are some filesystem implementations wherein ENOSPC could be returned at close() rather than the preceding write(). (For instance, the HPUX man page for close() states that this never happens on local filesystems but can happen on NFS.) So it'd be possible for SlruPhysicalWritePage to think it had successfully written a page when it hadn't. This would allow a checkpoint to complete :-( Chris, what's your platform exactly, and what kind of filesystem are you storing pg_clog on? regards, tom lane
В списке pgsql-hackers по дате отправления: