Thread: mylog() + qlog() implementation
Hello, I noticed that in misc.c:mylog() (same goes for qlog()), the logfile is opened as "w" or "wb" in the WIN32 case. I've also noticed that sometimes my log files while testing get truncated if I open multiple connections through the odbc driver, close them down, and then open some more, while still using the same custom-build application without exiting (thus generate_filename() picks up the same pid for it). Hiroshi will probably need to verify this, otherwise it's all speculation. Would it be possible to consider fopen()ing the mylog file as "a" and "ab" in WIN32 for appending vs zeroing out the log file, as described in the attached patch? Thanks, Kristis
Attachment
Kristis Makris <kristis.makris@datasoft.com> writes: > -#define PG_BINARY_W "w" > +#define PG_BINARY_W "a" Surely this would break a lot of other uses? I don't object to writing logfiles in append mode... but the PG_BINARY_x symbols probably shouldn't be used for logfiles in the first place, and in any case we need to distinguish "write" from "append" mode. I think a more extensive patch that defines suitable PG_APPEND symbols may be called for. regards, tom lane
Tom Lane wrote: > > Kristis Makris <kristis.makris@datasoft.com> writes: > > -#define PG_BINARY_W "w" > > +#define PG_BINARY_W "a" > > Surely this would break a lot of other uses? Practically no. misc.c is the only place where PG_BINARY_W is used. > I don't object to writing logfiles in append mode... but the > PG_BINARY_x symbols probably shouldn't be used for logfiles > in the first place, and in any case we need to distinguish > "write" from "append" mode. I think a more extensive patch > that defines suitable PG_APPEND symbols may be called for. I would define PG_BINARY_A and change misc.c to use PG_BINARY_A. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/
This is more of a release management question/suggestion. Are there any plans for tagging individual components in the CVS repository with their own "private", if you will, tags ? For example, I have found out that v7.01.00.08 of the ODBC driver is the most suitable for the needs of an application I'm maintaining, since the behaviour of both bugs in the application and driver produce the desired results. In cases were minor improvements could be integrated, such as the append feature of the log file, I would be interested in manually applying such changes. Had there been a private tag with a name along the lines of REL_7_1_2_ODBC_7_01_08 I could check out against it and privately maintain a separate driver release that meets my needs. I'd like to propose such a tagging scheme. I definitely do not have the internals understanding required to judge whether such a process could be carried out uniformly across different subsystems within postgres, or comprehend the practical implications of maintaing such a process, but it does seem like a useful thing to do in the ODBC driver's case. I understand that going forward with such a scheme will not fix *my* current problem, but others could be interested in such tags in the future. Thanks for any consideration in this. Kristis On Wed, 2002-05-08 at 18:36, Hiroshi Inoue wrote: > Tom Lane wrote: > > > > Kristis Makris <kristis.makris@datasoft.com> writes: > > > -#define PG_BINARY_W "w" > > > +#define PG_BINARY_W "a" > > > > Surely this would break a lot of other uses? > > Practically no. misc.c is the only place where > PG_BINARY_W is used. > > > I don't object to writing logfiles in append mode... but the > > PG_BINARY_x symbols probably shouldn't be used for logfiles > > in the first place, and in any case we need to distinguish > > "write" from "append" mode. I think a more extensive patch > > that defines suitable PG_APPEND symbols may be called for. > > I would define PG_BINARY_A and change misc.c to use > PG_BINARY_A. > > regards, > Hiroshi Inoue > http://w2422.nsk.ne.jp/~inoue/ >
Kristis Makris wrote: > > This is more of a release management question/suggestion. > > Are there any plans for tagging individual components in the CVS > repository with their own "private", if you will, tags ? No. > For example, I > have found out that v7.01.00.08 of the ODBC driver is the most suitable > for the needs of an application I'm maintaining, since the behaviour of > both bugs in the application and driver produce the desired results. Are you referring to the [ODBC] Are multiple selects of the same field allowed using CRecordset::GetFieldValue() ? If you don't hate to compile the driver by yourself, please remove or comment the following lines at near the end of copy_and_convert_field in convert.c and try it. if (result == COPY_OK && stmt->current_col >= 0) opts->bindings[stmt->current_col].data_left = 0; I hope the latest driver is the best one for anyone. > > I'd like to propose such a tagging scheme. I definitely do not have the > internals understanding required to judge whether such a process could > be carried out uniformly across different subsystems within postgres, or > comprehend the practical implications of maintaing such a process, but > it does seem like a useful thing to do in the ODBC driver's case. I > understand that going forward with such a scheme will not fix *my* > current problem, but others could be interested in such tags in the > future. Unfortunately there's no consensus on it and seems hard to get any consensus in the near future. Probably we must have another place to do it, if it is really needed. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/