From: | Randolf Richardson <rr(at)8x(dot)ca> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Disaster! |
Date: | 2004-01-25 07:36:59 |
Message-ID: | Xns947AEE1192C04rr8xca@200.46.204.72 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"gsstark(at)mit(dot)edu (Greg Stark)" stated in
comp.databases.postgresql.hackers:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
>> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)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(at)8x(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-01-25 07:49:42 | Re: compile failure on xmalloc() |
Previous Message | Christopher Kings-Lynne | 2004-01-25 06:47:35 | Re: Disaster! |