Bruce Momjian <[EMAIL PROTECTED]> writes:
> I should have said "in the _new_ code" above.
Ah, my mistake. I was looking at the original coding.
> Agreed. However, I have never seen it stated that file descriptors are
> freeded on elog(ERROR). I certainly didn't know that. If we are going
> t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Actually, my recommendation is to remove it altogether. The mechanisms
> >> are in place to close allocated files after elog(), so why waste thought
> >> and code space to release them manually?
>
> > Fix applied. There is a FileF
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Actually, my recommendation is to remove it altogether. The mechanisms
>> are in place to close allocated files after elog(), so why waste thought
>> and code space to release them manually?
> Fix applied. There is a FileFree() just below this in the
Tom Lane wrote:
> Brent Verner <[EMAIL PROTECTED]> writes:
> > | This coding is WRONG. You do not use fclose() to release a file
> > | opened with AllocateFile.
>
> > s/fclose/FreeFile/
>
> Actually, my recommendation is to remove it altogether. The mechanisms
> are in place to close allocat
Brent Verner <[EMAIL PROTECTED]> writes:
> | This coding is WRONG. You do not use fclose() to release a file
> | opened with AllocateFile.
> s/fclose/FreeFile/
Actually, my recommendation is to remove it altogether. The mechanisms
are in place to close allocated files after elog(), so why wa
Brent Verner wrote:
> [2002-02-23 20:27] Tom Lane said:
> | Bruce Momjian <[EMAIL PROTECTED]> writes:
> | > {
> | > + struct stat st;
> | > fp = AllocateFile(filename, PG_BINARY_R);
>
> | > + fclose(fp);
> |
> | This coding is WRONG. You
