Re: libpq debug log - Mailing list pgsql-hackers

From Tom Lane
Subject Re: libpq debug log
Date
Msg-id 3337422.1617229905@sss.pgh.pa.us
Whole thread Raw
In response to Re: libpq debug log  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: libpq debug log  ("'alvherre@alvh.no-ip.org'" <alvherre@alvh.no-ip.org>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: New IndexAM API controlling index vacuum strategies
Next
From: Melanie Plageman
Date:
Subject: Re: Assertion failure with barriers in parallel hash join