From: | Donald Dong <xdong(at)csumb(dot)edu> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unified logging system for command-line programs |
Date: | 2019-01-10 04:57:59 |
Message-ID: | 38A737AF-9C4E-483F-B8DD-7B5E718B66C8@csumb.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I think this patch is a nice improvement!
On Jan 3, 2019, at 2:08 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Or we could just add an ERROR variant that doesn't exit. Years back
> I'd proposed that we make the log level a bitmask, but it could also
> just be something like CALLSITE_ERROR or something roughly along those
> lines. There's a few cases in backend code where that'd be beneficial
> too.
I think the logging system can also be applied on pg_regress. Perhaps even
for the external frontend applications?
The patch cannot be applied directly on HEAD. So I patched it on top of
60d99797bf. 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 ()
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.
Thank you,
Donald Dong
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-01-10 05:25:45 | Re: [Sender Address Forgery]Re: error message when subscription target is a partitioned table |
Previous Message | Amit Kapila | 2019-01-10 03:58:07 | Re: Displaying and dumping of table access methods |