RE: libpq debug log - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: libpq debug log
Date
Msg-id OSBPR01MB29821BCBE1A19CA353403DFAFEB99@OSBPR01MB2982.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: libpq debug log  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
List pgsql-hackers
From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> I realized that existing libpq regression tests in src/test/examples do not
> test PQtrace(). At the same time, no other functions Is calling PQtrace(),
> so it's expected that by default if there are no compilation errors, then it
> will pass all the tests. And it did.
> 
> So to check that the tracing feature is enabled and, as requested, outputs
> a trace file, I temporarily modified a bit of testlibpq.c instead **based from
> my current environment settings**, and ran the regression test.

To run the tracing code in much more extensive cases, can you try running the whole SQL regression test with the
tracingenabled?  That is, run "make check-world" in the top directory of the source tree.
 

To enable tracing in every connection, you can probably insert PQtrace() call just before the return statement here in
connectDBComplete(). If you have enough disk space, it's better to accumulate the trace output by passing "a" to
fopen().

        switch (flag)
        {
            case PGRES_POLLING_OK:
                return 1;       /* success! */



Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Next
From: Jaime Casanova
Date:
Subject: Assertion fail with window function and partitioned tables