chore(queries): pg_stat_user_tables: skip tables with an AccessExclus…

…iveLock

Methods computing size of tables or related objects (such as `pg_total_relation_size` or `pg_table_size`) acquires an
AccessShareLock. This happens while refreshing a Materialized View or when ALTER'ing a table.

A fix has been implemented to estimate (very precisely) the size of materialized views, so the query does not wait
while a materialized view is being refreshed. However, this did not fix the issue when a table is being ALTER'ed:
the SQL query waits for the AccessExclusiveLock being released, and this can take several minutes. It is an issue
because the exporter stops exporting any data while the ALTER is running.

To prevent that, we check in `pg_locks` table if an AccessExclusiveLock exists: if it does exist, we skip it:
- the exporter will compute size for tables with no AccessExclusiveLock locks
- the exporter will not be blocked

This is not perfect: there may have a race condition where the Lock is being acquired just before the query is being executed.
However, we believe this should prevent the common cases where an ALTER is run for a long time (several minutes),
and we consider having the exporter blocked for a single execution acceptable.

content/tutorials/postgresql-exporter.queries.yaml

@@ -219,6 +219,9 @@ pg_stat_user_tables:
           ) idx
         GROUP BY c.oid
       ) t ON u.relid = t.oid
+    WHERE NOT EXISTS (
+      SELECT 1 FROM pg_locks WHERE pg_locks.relation = u.relid AND pg_locks.mode = 'AccessExclusiveLock'
+    )
     ;
   metrics:
     - datname: