Re: libpq debug log

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: libpq debug log
Дата
Msg-id 3337422.1617229905@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: libpq debug log  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: libpq debug log
Список pgsql-hackers
I wrote:
> What I suspect is some Windows dependency in the way that
> 001_libpq_pipeline.pl is setting up the trace output files.

While this may have little to do with drongo's issue,
I'm going to take exception to this bit that I see that
the patch added to PQtrace():

    /* Make the trace stream line-buffered */
    setvbuf(debug_port, NULL, _IOLBF, 0);

I do not like that on two grounds:

1. The trace file handle belongs to the calling application,
not to libpq.  I do not think libpq has any business editorializing
on the file's settings.

2. POSIX says that setvbuf() must be done before any other
operation on the file.  Since we have no way to know whether
any output has already been written to the trace file, the
above is a spec violation.


... and as for an actual explanation for drongo's issue,
I'm sort of wondering why libpq_pipeline.c is opening the
trace file in "w+" mode rather than vanilla "w" mode.
That seems unnecessary, and maybe it doesn't work so well
on Windows.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: New IndexAM API controlling index vacuum strategies
Следующее
От: Melanie Plageman
Дата:
Сообщение: Re: Assertion failure with barriers in parallel hash join