The buckets are now created with the start time a modulus of the bucket time size.
So if we have a 10 second bucket, the start times would reflect that:
- Bucket1: 00:00:00
- Bucket2: 00:00:10
- Bucket3: 00:00:20
...
Previously, the start time of the bucket was aligned with the first query that
arrives in that bucket. However, now the behaviour is changed. So, even if the
first query for bucket 2 arrives at 00:00:13, the start time would still be set
to 00:00:10.
This change now makes the bucketing separated out by fixed time windows so that
external applications can easily consume that data and chart it.
Also, as part of this change, locking of pgss is updated now and extended
to last the bucket related changes.
pg_stat_monitor.pgsm_normalized_query needs to be 0 by default because
people will get Query examples. This is one of the main user-faced
advantages of pgsm over pgss (pg_stat_statements).
PMM-9951 Fix for forked Repo
PMM-9951 Checking with forked repo and custom branch
PMM-9951 fix the branch
PMM-9951 testing the github properties
PMM-9951 testing
PMM-9951 testing the changes
PMM-9951 changing permissions
PMM-9951 handle the repo
PMM-9951 permissions check
PMM-9951 permissions check
PMM-9951 remove not needed ones
PMM-9951 checks permissions
PMM-9951 testing
PMM-9951 testing another workflow
PMM-9951 test changes
PMM-9951 Final Push with all changes
PMM-9951
There was no maximum limit set for the number of maximum histograms
bucket, which can lead to a crash in case of higher value.
PG-382: Adjust the maximum value for histogram buckets.
Fix the regression issue related to GUC and set the maximum
buckets value correctly.
PG-382: Adjust the maximum value for histogram buckets.
Fix the TAP test cases.
There was no maximum limit set for the number of maximum histograms
bucket, which can lead to a crash in case of higher value.
PG-382: Adjust the maximum value for histogram buckets.
Fix the regression issue for PostgreSQL-12.
PG-382: Adjust the maximum value for histogram buckets.
Fix the TAP test cases.
While analyzing the pg_stat_monitor installation scripts I found several
vulnerabilities. pg_stat_monitor uses CREATE OR REPLACE to install its
functions which is a security hazard. An attacker can precreate the functions
have a superuser install the extension and after installation the attacker
can switch out the function with a malicious version since he would still
be the owner of the function. Instead of CREATE OR REPLACE the installation
script should use plain CREATE to prevent this attack.
For reference
https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-SECURITYhttps://github.com/timescale/pgspot
While analyzing the pg_stat_monitor installation scripts I found several
vulnerabilities. pg_stat_monitor uses CREATE OR REPLACE to install its
functions which is a security hazard. An attacker can precreate the functions
have a superuser install the extension and after installation the attacker
can switch out the function with a malicious version since he would still
be the owner of the function. Instead of CREATE OR REPLACE the installation
script should use plain CREATE to prevent this attack.
For reference
https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-SECURITYhttps://github.com/timescale/pgspot
Hamid Akhtar
Ibrar Ahmed
Kai Wagner
Anastasia Alexadrova
puneet0191
Ibrar Ahmed
Ibrar Ahmed
Francisco Miguel Biete