Activity snapshots: Normalize queries for "filter_query_sample = normalize"

[lfittl]

For historic reasons, we were only normalizing pg_stat_activity query texts when filter_query_sample was set to all, not normalize, which has a similar intent.

Whilst we could also control the filtering of pg_stat_activity query texts with the filter_query_text setting (which today controls whether pg_stat_statements query texts are re-normalized, and is enabled by default), this is intentionally
not done here. The main motivation to not do this for now are performance implications of running normalize every 10 seconds for many active queries, and we may adjust this in a future commit based on more benchmarks.

[keiko713]

memo: https://pganalyze.com/docs/collector/settings#pii-filtering-settings

filter_query_sample

default: none, Either none, normalize or all

By default the pganalyze collector does not filter data. Our recommended configuration for servers containing sensitive data is as follows: filter_query_sample: normalize

Note the normalize setting for filter_query_sample, which will remove all query parameter values from query samples, including those contained within automatically collected EXPLAIN plans.

filter_query_text

default: unparsable, Either none or unparsable

[keiko713]

Thanks for adjusting, I think it's good to do this way first and we can revisit if it's okay to change more widely in the future.

Minor note: it might be nice to have some comment for why we're passing "unparseable" to util.NormalizeQuery. I don't think the behavior will be much different here if we pass it or server.Config.FilterQueryText so I'm gonna approve anyways, but it would be nice if the reason is mentioned well. Maybe you're doing so so that we can control the behavior when the error happens during the normalization? (and make sure not to use the original query with the error case?)

[lfittl]

Minor note: it might be nice to have some comment for why we're passing "unparseable" to util.NormalizeQuery. I don't think the behavior will be much different here if we pass it or server.Config.FilterQueryText so I'm gonna approve anyways, but it would be nice if the reason is mentioned well. Maybe you're doing so so that we can control the behavior when the error happens during the normalization? (and make sure not to use the original query with the error case?)

Good point, that's a bit confusing - adding a comment.