Re: Disaster!
От | Randolf Richardson |
---|---|
Тема | Re: Disaster! |
Дата | |
Msg-id | Xns947AEE1192C04rr8xca@200.46.204.72 обсуждение исходный текст |
Ответ на | Disaster! (Christopher Kings-Lynne <chriskl@familyhealth.com.au>) |
Ответы |
Re: Disaster!
|
Список | pgsql-hackers |
"gsstark@mit.edu (Greg Stark)" stated in comp.databases.postgresql.hackers: > Tom Lane <tgl@sss.pgh.pa.us> writes: > >> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: >> > FreeBSD 4.7/4.9 and the UFS filesystem >> >> Hm, okay, I'm pretty sure that that combination wouldn't report ENOSPC >> at close(). We need to fix the code to check close's return value, >> probably, but it seems we still lack a clear explanation of what >> happened to your database. > > The traditional Unix filesystems certainly don't return errors at close. > Even NFS doesn't traditionally do so. I think NFSv3 can if the server > disappears after the client obtains a lease on a piece of the file, but > I'm not sure if ENOSPC is a possible failure mode. [sNip] Why shouldn't the close() function return an error? If an invalid file handle was passed to it, it most certainly should indicate this since it's always possible for a separate thread to close it first (or other reasons as well). -- Randolf Richardson - rr@8x.ca Vancouver, British Columbia, Canada "We are anti-spammers. You will confirm subscriptions. Resistance is futile." Please do not eMail me directly when responding to my postings in the newsgroups.
В списке pgsql-hackers по дате отправления: