Since Postgres 14, we can get statement's queryid in logs. I think it could be useful to get queryid in reports.
Thus, it is easier to find a query in logs or in pg_stat_statements by looking its queryid.
While we're at it, we can exclude by queryid.
This PR contains:
Fix parsing if %Q flag is used (and also for %b):
@@ -18144,12 +18199,12 @@ sub build_log_line_prefix_regex
if ($llp =~ s/(.*)\%q(.*)/$1$2/) {
$q_prefix = $1;
}
while ($llp =~ s/(\%[audrhpntmlscvxie])/$regex_map{"$1"}->[1]/) {
while ($llp =~ s/(\%[audrhpQntmlscvxieb])/$regex_map{"$1"}->[1]/) {
push(@$param_list, $regex_map{"$1"}->[0]);
}
my $q_prefix_param = [];
if ($q_prefix) {
while ($q_prefix =~ s/(\%[audrhpntmlscvxie])/$regex_map{"$1"}->[1]/) {
while ($q_prefix =~ s/(\%[audrhpQntmlscvxieb])/$regex_map{"$1"}->[1]/) {
push(@$q_prefix_param, $regex_map{"$1"}->[0]);
Display queryid when information is available
Allow filter on queryid
I think I spoted an old bug in store_temporary_and_lock_infos:
Hello Gilles,
Since Postgres 14, we can get statement's queryid in logs. I think it could be useful to get queryid in reports. Thus, it is easier to find a query in logs or in pg_stat_statements by looking its queryid.
While we're at it, we can exclude by queryid.
This PR contains:
Fix parsing if
%Q
flag is used (and also for%b
):while ($llp =~ s/(\%[audrhpntmlscvxie])/$regex_map{"$1"}->[1]/) {
while ($llp =~ s/(\%[audrhpQntmlscvxieb])/$regex_map{"$1"}->[1]/) { push(@$param_list, $regex_map{"$1"}->[0]); } my $q_prefix_param = []; if ($q_prefix) {
while ($q_prefix =~ s/(\%[audrhpntmlscvxie])/$regex_map{"$1"}->[1]/) {
while ($q_prefix =~ s/(\%[audrhpQntmlscvxieb])/$regex_map{"$1"}->[1]/) { push(@$q_prefix_param, $regex_map{"$1"}->[0]);
Display queryid when information is available
Allow filter on queryid
I think I spoted an old bug in
store_temporary_and_lock_infos
:If you are interested, I will also update pgbadger_tools. I also added queryid.log.gz with a sample containing queryid.
Regards,