Unable to run a query longer than 10 mins against postgres DB

I have been grinding on for quite some time on why "now" any query (or model refresh) will time-out after 10 mins, being very certain a query could run for longer in the "past".

The only likely candidate I can find is this commit

Unless someone can tell me I am reading the context of this code all wrong, or come forward and show they are running queries for longer against a PostgreSQL engine.

troubleshooting info?

my bad

  "browser-info": {
    "language": "nb",
    "platform": "Win32",
    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36",
    "vendor": "Google Inc."
  "system-info": {
    "file.encoding": "UTF-8",
    "java.runtime.name": "OpenJDK Runtime Environment",
    "java.runtime.version": "11.0.21+9",
    "java.vendor": "Eclipse Adoptium",
    "java.vendor.url": "https://adoptium.net/",
    "java.version": "11.0.21",
    "java.vm.name": "OpenJDK 64-Bit Server VM",
    "java.vm.version": "11.0.21+9",
    "os.name": "Linux",
    "os.version": "6.1.61-85.141.amzn2023.x86_64",
    "user.language": "en",
    "user.timezone": "Europe/Oslo"
  "metabase-info": {
    "databases": [
    "hosting-env": "unknown",
    "application-database": "postgres",
    "application-database-details": {
      "database": {
        "name": "PostgreSQL",
        "version": "11.19"
      "jdbc-driver": {
        "name": "PostgreSQL JDBC Driver",
        "version": "42.5.4"
    "run-mode": "prod",
    "version": {
      "date": "2023-11-17",
      "tag": "v0.47.8",
      "branch": "?",
      "hash": "639fa5e"
    "settings": {
      "report-timezone": null

New year, new possibilities.
Would it be possible to remove this hardcoded and arbitary limit?
As noted in the pr, a statement timeout may be set in the connection string if it is needed.

as you can imagine, we put that limit in our code because of a reason: we lock threads when doing so and we have people that save hundreds of models. I would suggest you fork the project, remove that line and have a Metabase tailored to your needs

Your reasoning does not make sense. The transaction is clearly per query/model, so the number of models (we have 52 atm.) does not factor in. There may be longer running transactions related to sync, finger printing, or what ever; but why is 10 mins a magic number?

sync and fingerprinting have 1 thread per operation, not 1 thread for the entire process.

I will create a feature request to make the limit configurable, but I can't provide a timeframe for a resolution of it

1 Like