> On Jan 11, 2019, at 9:14 AM, Peter Eisentraut <peter.eisentraut@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?
