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
