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 code:
> if (!pipe)
> FreeFile(fp);
> We don't need the if (!pipe) because this code is in an else of
> if(pipe). For clarity, it seems the FreeFile call makes sense.
Huh? That FreeFile is *necessary* because it is not in an elog(ERROR)
path; and by my reading the "if (!pipe)" is needed too.
We do have a fair amount of other code that releases resources just
before doing elog(ERROR); so Brent was just emulating code he saw
elsewhere... but it's a coding habit I think we should move away from.
If the resource in question would be released anyway during error
recovery, then I don't see the value of doing it "by hand"; it just
bloats the backend (and adds potential for error, as in this case).
The only exception I'd make is for the case of releasing a spinlock or
LWLock; it's better to release the lock ASAP so as not to block other
backends longer than necessary.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
