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
[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 do not use fclose() to release a file
| opened wi
[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 do not use fclose() to release a file
| opened wi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> {
> + struct stat st;
> fp = AllocateFile(filename, PG_BINARY_R);
> !
> ! if (fp == NULL)
> elog(ERROR, "COPY command, running in backend with "
>
OK'ed by Peter.
Patch applied. Thanks.
---
Brent Verner wrote:
> [2002-01-17 07:08] Brent Verner said:
> | [2002-01-16 17:47] Douglas Trainor said:
> | | I'd like to report a bug in 7.1.3 psql (at least on a 64-bit Alpha
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Brent Verner wrote:
> [2002-01-17 07:08] Brent
This has been saved for the 7.3 release:
http://candle.pha.pa.us/cgi-bin/pgpatches2
---
Brent Verner wrote:
> [2002-01-17 07:08] Brent Verner said:
> | [2002-01-16 17:47] Douglas Trainor said:
> | | I'd like to rep
[2002-01-17 07:08] Brent Verner said:
| [2002-01-16 17:47] Douglas Trainor said:
| | I'd like to report a bug in 7.1.3 psql (at least on a 64-bit Alpha Linux box).
| | Maybe someone can confirm this or maybe it's fixed in 7.2
|
| The attached patch is for 7.2, but might apply (with some fuzz) to
[2002-01-16 17:47] Douglas Trainor said:
| I'd like to report a bug in 7.1.3 psql (at least on a 64-bit Alpha Linux box).
| Maybe someone can confirm this or maybe it's fixed in 7.2
The attached patch is for 7.2, but might apply (with some fuzz) to 7.1.x.
files:
src/backend/commands/copy.c
s
I'd like to report a bug in 7.1.3 psql (at least on a 64-bit Alpha Linux box).
Maybe someone can confirm this or maybe it's fixed in 7.2
The 7.1 documentation ( http://www.postgresql.org/idocs/index.php?sql-copy.html )
for COPY ala
COPY table FROM 'filename'
says that if it fails you get fe
15 matches
Mail list logo
