BUG #16049: log_line_prefix=%a and log_connections - application_name missing
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
The following bug has been logged on the website:
Bug reference: 16049
Logged by: death lock
Email address: deathlock13@gmail.com
PostgreSQL version: 9.5.19
Operating system: Debian 11
Description:
[unknown] LOCATION: BackendRun, postmaster.c:4300
[unknown] DEBUG: 00000: InitPostgres
[unknown] LOCATION: InitPostgres, postinit.c:555
[unknown] DEBUG: 00000: my backend ID is 4
[unknown] LOCATION: SharedInvalBackendInit, sinvaladt.c:324
[unknown] DEBUG: 00000: StartTransaction
[unknown] LOCATION: ShowTransactionState, xact.c:4975
[unknown] DEBUG: 00000: name: unnamed; blockState: DEFAULT; state:
INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
[unknown] LOCATION: ShowTransactionStateRec, xact.c:5004
# log_connections - application_name MIA
[unknown] LOG: 00000: connection authorized: user=postgres
database=postgres
[unknown] LOCATION: PerformAuthentication, postinit.c:257
psql DEBUG: 00000: CommitTransaction
psql LOCATION: ShowTransactionState, xact.c:4975
psql DEBUG: 00000: name: unnamed; blockState: STARTED; state:
INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
...
psql DEBUG: 00000: proc_exit(0): 4 callbacks to make
psql LOCATION: proc_exit_prepare, ipc.c:187
# log_disconnections=on
psql LOG: 00000: disconnection: session time: 0:00:10.280 user=postgres
database=postgres host=[local]
PG Bug reporting form <noreply@postgresql.org> writes:
# log_connections - application_name MIA
[unknown] LOG: 00000: connection authorized: user=postgres
database=postgres
This was changed about a year ago, see
/messages/by-id/CAHJZqBB_Pxv8HRfoh+AB4KxSQQuPVvtYCzMg7woNR3r7dfmopw@mail.gmail.com
so v12 will do what you want.
regards, tom lane
"will do what you want." Not exactly - I want it to appear according
to my log_line_prefix - 4 ex. ='%t|%p|%a|%d|%u|%h| '
I've used that patch on 9.5.19
In elog.c there's : const char *appname = application_name; // line 2357
other cases have : const char *username = MyProcPort->user_name;
After adding 'MyProcPort->' to %a case '|psql|' shows up like I
wanted .. but connection process Segfaults :/
I've tracked it to postinit.c - process_startup_options() - this loop
: while (gucopts) {...}
gucopts = list_head(port->guc_options);
ereport(LOG, (errmsg(" +++ process_startup_options : [%s] ",
gucopts))); // adding this line returns :
2019-10-15 14:28:03 CEST|9760|psql|postgres|postgres|[local]|
LOCATION: PerformAuthentication, postinit.c:257
2019-10-15 14:28:03 CEST|9760|psql|postgres|postgres|[local]| LOG:
00000: +++ process_startup_options : [local all
all trust]
2019-10-15 14:28:03 CEST|9760|psql|postgres|postgres|[local]|
LOCATION: process_startup_options, postinit.c:1066
Sorry 4 nagging , any pointers much appreciated
Show quoted text
On 10/11/19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
This was changed about a year ago, see
/messages/by-id/CAHJZqBB_Pxv8HRfoh+AB4KxSQQuPVvtYCzMg7woNR3r7dfmopw@mail.gmail.com
so v12 will do what you want.
regards, tom lane
Not sure where I messed up yesterday , slimmed patch in attachment
--- postgresql-9.5.19/src/backend/utils/error/elog.c
+++ postgresql-9.5.19/src/backend/utils/error/elog.c
@@ -2354,7 +2354,9 @@
case 'a':
if (MyProcPort)
{
- const char *appname = application_name;
+
+ // ereport(LOG, (errmsg(" ++ MyProcPort : [%s] ", application_name)));
+ const char *appname = MyProcPort->application_name;adding 'MyProcPort->' works great for me
1. why appname =application_name doesn't produce err , but trying to
print application_name value -> SegFault ?
Attachments:
pg95appname.patchtext/x-patch; charset=US-ASCII; name=pg95appname.patchDownload+27-1
On Wed, Oct 16, 2019 at 01:42:20PM +0200, death lock wrote:
Not sure where I messed up yesterday , slimmed patch in attachment
As Tom has mentioned on this thread, this has been committed to v12,
and it seems that this qualifies as a new feature so it won't be
back-patched. FWIW, here is the actual commit, your patch could be
more refined based on it I guess:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=8bddc86400
--
Michael