Open kaaveland opened 7 months ago
Unless judiciously reset, pg_stat_statements
is going to contain a lot of different stuff. All DDL commands, f. ex. It's probably only interesting to identify queries that run as part of normal application code, so we need some way to find those based on query text. One idea is to simply test if we can explain
it. It is often (always?) a syntax error to explain alter
statements and it works with "unusual" queries like refresh materialized view
. Even though we know which locks a transaction will take, there's still a ways to go to test for conflict. We may be able to use this idea: https://github.com/kaaveland/eugene/issues/4 or we might have to try a more manual approach with pg_query.rs
, or we can try to run the query itself in a transaction, assuming it doesn't have any placeholders that we can't automatically assign.
Per #4, it's pretty easy to detect which tables we need to lock at AccessShare
or higher now, and which statements that are DML, so we can start working on this now.
We should try to accept a dump (
.csv.gz
or.csv
) ofpg_stat_statements
, or optionally just usepg_stat_statements
in the connected database to see if we could pick up queries that would conflict with locks taken by the migration script.