> On Jan 11, 2019, at 9:14 AM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: > >> 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?
Thank you. I did add a new call for my local testing. There are no more errors after re-applying the patch on master. >> 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 Thank you for the reference. That's very helpful! I noticed in some places such as pg_log_error("no data directory specified"); fprintf(stderr, _("You must identify the directory where the data for this database system\n" ... and pg_log_warning("enabling \"trust\" authentication for local connections"); fprintf(stderr, _("You can change this by editing pg_hba.conf or using the option -A, or\n" "--auth-local and --auth-host, the next time you run initdb.\n")); , pg_log does not completely replace fprintf. Would it be better to use pg_log so the logging level can also filter these messages?
