PG-1459 Keep username and datname fields empty if we cannont get real values

[artemgavrilov]

PG-1459

Description

Keep username and datname fields empty if we cannont get real values

Links

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.34%. Comparing base (b6ffd37) to head (046589e).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
pg_stat_monitor.c	66.66%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #636      +/-   ##
==========================================
+ Coverage   85.89%   86.34%   +0.44%     
==========================================
  Files           3        3              
  Lines        1354     1347       -7     
  Branches      218      217       -1     
==========================================
  Hits         1163     1163              
+ Misses         91       87       -4     
+ Partials      100       97       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jeltz]

I feel the title of the PR and the commit are misleading. To me the biggest change seems to be that we collect the information earlier.

[jeltz]

There isnät even a test for the new empty behvior.

[artemgavrilov]

@jeltz I added test and changed commit/PR message

[jeltz]

The code looks good, but I think it would be nicer as two commits:

1. Which fixes the bug and adds a test case
2. Which changes the message for when we cannot get the user from the previous message to the empty string

This means we can trivially revert 2 if people change their minds.

I also think "collecting" likely should be "collection" but I am not a native speaker either.

[artemgavrilov]

The code looks good, but I think it would be nicer as two commits:

1. Which fixes the bug and adds a test case

2. Which changes the message for when we cannot get the user from the previous message to the empty string

This means we can trivially revert 2 if people change their minds.

I also think "collecting" likely should be "collection" but I am not a native speaker either.

Damn, I was wrong about transactions. It tuned out that subtransaction state changed (internal structure), not real transaction. So we still can get username and datname if user made rollback manually. However getting this fields earlier solves another problem, I'll address them in another PR.

This PR now covers only actual bug report.