Re: Unified logging system for command-line programs

On 10/01/2019 05:57, Donald Dong wrote:
> I think the logging system can also be applied on pg_regress. Perhaps even
> for the external frontend applications?

Could be done, yes.  A bit at a time. ;-)

> The patch cannot be applied directly on HEAD. So I patched it on top of 
> 60d99797bf.

Here is an updated patch with the merge conflicts of my own design
resolved.  No functionality changes.

> When I call pg_log_error() in initdb, I see
> 
> Program received signal SIGSEGV, Segmentation fault.
> __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
> 62      ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
> (gdb) bt
> #0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
> #1  0x0000555555568f96 in dopr.constprop ()
> #2  0x0000555555569ddb in pg_vsnprintf ()
> #3  0x0000555555564236 in pg_log_generic ()
> #4  0x000055555555c240 in main ()

What do you mean exactly by "I call pg_log_error()"?  The existing calls
in initdb clearly work, at least some of them, that is covered by the
test suite.  Are you adding new calls?

> I'm not sure what would be causing this behavior. I would appreciate
> references or docs for testing and debugging patches more efficiently.
> Now I'm having difficulties loading symbols of initdb in gdb.

The above looks like you'd probably get a better insight by compiling
with -O0 or some other lower optimization setting.

There is also this:
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services