Re: Disaster!

Поиск
Список
Период
Сортировка
От Randolf Richardson
Тема Re: Disaster!
Дата
Msg-id Xns947AEE1192C04rr8xca@200.46.204.72
обсуждение исходный текст
Ответ на Disaster!  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Ответы Re: Disaster!  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Randolf Richardson
Дата:
Сообщение: Re: Copyright (C) 1996-2002
Следующее
От: Kevin Brown
Дата:
Сообщение: Re: index scan with functional indexes -- solved