Because of large holes in the query design, it is easy for users to construct queries that result in very large tables being joined together, perhaps in triplicate. This is very bad and must be solved.
However, until that problem is solved, users can easily lock up Magma with long-running queries just by hitting reload on their favorite manifest a few times. This locks up Timur, which can't do anything without Magma data.
To prevent this disastrous situation from persisting, we can use the postgres variable statement_timeout; probably by adding this setting to the database role for magma. This way at least those queries will die and restore normal function within whatever statement_timeout is - maybe one minute?
Because of large holes in the query design, it is easy for users to construct queries that result in very large tables being joined together, perhaps in triplicate. This is very bad and must be solved.
However, until that problem is solved, users can easily lock up Magma with long-running queries just by hitting reload on their favorite manifest a few times. This locks up Timur, which can't do anything without Magma data.
To prevent this disastrous situation from persisting, we can use the postgres variable statement_timeout; probably by adding this setting to the database role for magma. This way at least those queries will die and restore normal function within whatever statement_timeout is - maybe one minute?