Restart loop / "Could not create schema migrations table" after unclean shutdown (PostgreSQL still in crash recovery) #5591

HanwGu · 2026-08-07T06:58:50Z

HanwGu
Aug 7, 2026

We found that the teslamate container is easy to restart when alpine rebooted, due to teslamate cannt connect to database.

Answered by JakobLichterfeld

Aug 7, 2026

Thanks for the logs — this is not an Alpine issue, and your data is most likely fine.

What the database log actually says:

15:17:23 database system was interrupted; last known up at 2026-08-02 08:43:29 UTC
15:17:41 syncing data directory (fsync), elapsed time: 10.01 s
15:17:21 received fast shutdown request          <-- stopped mid-recovery
15:17:42 database system was not properly shut down; automatic recovery in progress
15:17:44 database system is shut down            <-- recovery aborted

15:24:42 (second start)
15:24:46 redo starts at 0/4F65BE0
15:24:46 invalid record length at 0/4F65CE8      <-- normal: this is the end of the WAL
15:24:46 redo done at 0/4F65CB0
15:24:52 database sys…

View full answer

JakobLichterfeld · 2026-08-07T09:44:28Z

JakobLichterfeld
Aug 7, 2026
Maintainer

Thanks for posting. Not sure what your issue is. Can you please elaborate a bit more? TelsaMate Docker images are available for AMD64 and ARM64 and currently based on debian:trixie-slim

4 replies

HanwGu Aug 7, 2026
Author

hi，output by executing "docker compose logs database teslamate --tail 150".

Maybe database has been broken? We execute "poweroff" in alpine when docker running. How to fix it and keep the history drives？

logs below：

teslamate-1 | * The database does not exist
teslamate-1 | * The "schema_migrations" table, which Ecto uses for managing
teslamate-1 | migrations, was defined by another library
teslamate-1 | * There is a deadlock while migrating (such as using concurrent
teslamate-1 | indexes with a migration_lock)
database-1 | FROM regen r
teslamate-1 |
database-1 | JOIN drives d ON d.id = r.drive_id
teslamate-1 | To fix the first issue, run "mix ecto.create" for the desired MIX_ENV.
teslamate-1 |
database-1 | JOIN cars c ON c.id = d.car_id
teslamate-1 | To address the second, you can run "mix ecto.drop" followed by
teslamate-1 | "mix ecto.create", both for the desired MIX_ENV. Alternatively you may
teslamate-1 | configure Ecto to use another table and/or repository for managing
database-1 | WHERE r.regen_kwh > 0
teslamate-1 | migrations:
database-1 | AND d.start_ideal_range_km > d.end_ideal_range_km
teslamate-1 |
teslamate-1 | config :teslamate, TeslaMate.Repo,
teslamate-1 | migration_source: "some_other_table_for_schema_migrations",
teslamate-1 | migration_repo: AnotherRepoForSchemaMigrations
database-1 | )
database-1 | SELECT
teslamate-1 |
teslamate-1 | The full error report is shown below.
teslamate-1 |
database-1 | CONCAT((bin_idx * 5)::int, '~', (bin_idx * 5 + 5)::int, '°C') AS "温度区间",
database-1 | ROUND(AVG(recovery_pct)::numeric, 1) AS "平均回收率(%)",
database-1 | COUNT(*) AS "行程数"
teslamate-1 | ** (DBConnection.ConnectionError) [Elixir.TeslaMate.Repo] connection not available and request was dropped from queue after 4862ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
database-1 | FROM per_drive
teslamate-1 |
database-1 | WHERE recovery_pct IS NOT NULL
database-1 | GROUP BY bin_idx
teslamate-1 | 1. Ensuring your database is available and that you can connect to it
database-1 | ORDER BY bin_idx;
database-1 | 2026-08-02 08:43:28.825 UTC [29] LOG: checkpoint starting: time
teslamate-1 | 2. Tracking down slow queries and making sure they are running fast enough
database-1 | 2026-08-02 08:43:29.960 UTC [29] LOG: checkpoint complete: wrote 2 buffers (0.0%), wrote 0 SLRU buffers; 0 WAL file(s) added, 0 removed, 0 recycled; write=0.466 s, sync=0.134 s, total=1.151 s; sync files=1, longest=0.078 s, average=0.078 s; distance=10 kB, estimate=660 kB; lsn=0/4F65C38, redo lsn=0/4F65BE0
database-1 | 2026-08-02 08:54:27.307 UTC [4056] ERROR: canceling statement due to user request
teslamate-1 | 3. Increasing the pool_size (although this increases resource consumption)
database-1 | 2026-08-02 08:54:27.307 UTC [4056] CONTEXT: PL/pgSQL function wgs84_to_gcj02_lat(double precision,double precision) line 15 at IF
database-1 | 2026-08-02 08:54:27.307 UTC [4056] STATEMENT: WITH journey AS (SELECT start_date, end_date FROM drives WHERE id = 3)
database-1 | SELECT
teslamate-1 | 4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
database-1 | date AS "time",
database-1 | lat_for_map('https://wprd01.is.autonavi.com/appmaptile?lang=zh_cn&size=1&scale=1&style=7&x={x}&y={y}&z={z}', latitude, longitude) AS latitude,
teslamate-1 |
database-1 | lng_for_map('https://wprd01.is.autonavi.com/appmaptile?lang=zh_cn&size=1&scale=1&style=7&x={x}&y={y}&z={z}', latitude, longitude) AS longitude
database-1 | FROM positions, journey
database-1 | WHERE
teslamate-1 | See DBConnection.start_link/2 for more information
teslamate-1 |
database-1 | car_id = 1 AND (date BETWEEN journey.start_date AND journey.end_date)
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/adapters/sql.ex:1113: Ecto.Adapters.SQL.raise_sql_call_error/1
database-1 | ORDER BY date ASC
teslamate-1 | (elixir 1.19.5) lib/enum.ex:1688: Enum."-map/2-lists^map/1-1-"/2
database-1 | 2026-08-02 08:54:27.629 UTC [4062] ERROR: canceling statement due to user request
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/adapters/sql.ex:1234: Ecto.Adapters.SQL.execute_ddl/4
database-1 | 2026-08-02 08:54:27.629 UTC [4062] STATEMENT: WITH journey AS (SELECT start_date, end_date FROM drives WHERE id = 3)
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:779: Ecto.Migrator.verbose_schema_migration/3
database-1 | SELECT
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:563: Ecto.Migrator.lock_for_migrations/4
database-1 | date AS "time",
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:432: Ecto.Migrator.run/4
database-1 | AVG(convert_km(speed::numeric, 'km')) AS speed_kmh,
database-1 | AVG(power) AS Power,
database-1 | AVG(battery_level) AS SOC,
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:170: Ecto.Migrator.with_repo/3
teslamate-1 | nofile:1: (file)
database-1 | AVG(battery_heater::integer * 100) AS battery_heater,
teslamate-1 | 2026-08-07 23:31:25.436 [error] Could not create schema migrations table. This error usually happens due to the following:
teslamate-1 |
database-1 | AVG(ROUND(convert_m(elevation, 'm'))) AS elevation_m
database-1 | FROM
database-1 | positions, journey
database-1 | WHERE
database-1 | car_id = 1 AND (date BETWEEN journey.start_date AND journey.end_date)
database-1 | GROUP BY 1
database-1 | ORDER BY
teslamate-1 | * The database does not exist
database-1 | date ASC
teslamate-1 | * The "schema_migrations" table, which Ecto uses for managing
teslamate-1 | migrations, was defined by another library
database-1 | 2026-08-02 08:56:40.787 UTC [4061] ERROR: canceling statement due to user request
teslamate-1 | * There is a deadlock while migrating (such as using concurrent
teslamate-1 | indexes with a migration_lock)
teslamate-1 |
teslamate-1 | To fix the first issue, run "mix ecto.create" for the desired MIX_ENV.
teslamate-1 |
teslamate-1 | To address the second, you can run "mix ecto.drop" followed by
teslamate-1 | "mix ecto.create", both for the desired MIX_ENV. Alternatively you may
teslamate-1 | configure Ecto to use another table and/or repository for managing
teslamate-1 | migrations:
teslamate-1 |
database-1 | AVG(power) AS avg_power,
teslamate-1 | config :teslamate, TeslaMate.Repo,
teslamate-1 | migration_source: "some_other_table_for_schema_migrations",
teslamate-1 | migration_repo: AnotherRepoForSchemaMigrations
teslamate-1 |
teslamate-1 | The full error report is shown below.
database-1 | SUM(power::integer * speed::integer / 60.0) AS total_energy_consumed,
teslamate-1 |
teslamate-1 | ** (DBConnection.ConnectionError) [Elixir.TeslaMate.Repo] connection not available and request was dropped from queue after 4595ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
teslamate-1 |
database-1 | SUM(speed / 60.0) AS total_distance,
teslamate-1 | 1. Ensuring your database is available and that you can connect to it
database-1 | SUM(odometer_distance) AS total_odometer_distance,
database-1 | AVG(speed) AS avg_speed,
teslamate-1 | 2. Tracking down slow queries and making sure they are running fast enough
database-1 | car_id
teslamate-1 | 3. Increasing the pool_size (although this increases resource consumption)
database-1 | FROM
teslamate-1 | 4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
teslamate-1 |
database-1 | (SELECT
database-1 | drives.car_id,
database-1 | positions.speed,
teslamate-1 | See DBConnection.start_link/2 for more information
teslamate-1 |
database-1 | positions.power,
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/adapters/sql.ex:1113: Ecto.Adapters.SQL.raise_sql_call_error/1
database-1 | positions.elevation - LAG(positions.elevation) OVER (PARTITION BY positions.drive_id ORDER BY positions.date) AS elevation_diff,
teslamate-1 | (elixir 1.19.5) lib/enum.ex:1688: Enum."-map/2-lists^map/1-1-"/2
database-1 | positions.odometer - LAG(positions.odometer) OVER (PARTITION BY positions.drive_id ORDER BY positions.date) AS odometer_distance
database-1 | FROM
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/adapters/sql.ex:1234: Ecto.Adapters.SQL.execute_ddl/4
database-1 | drives
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:779: Ecto.Migrator.verbose_schema_migration/3
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:563: Ecto.Migrator.lock_for_migrations/4
database-1 | JOIN positions ON drives.id = positions.drive_id
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:432: Ecto.Migrator.run/4
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:170: Ecto.Migrator.with_repo/3
teslamate-1 | nofile:1: (file)
teslamate-1 | 2026-08-07 23:35:50.462 [error] Could not create schema migrations table. This error usually happens due to the following:
teslamate-1 | * The database does not exist
DifferentialData
teslamate-1 | * The "schema_migrations" table, which Ecto uses for managing
teslamate-1 | migrations, was defined by another library
database-1 | JOIN cars ON BinnedData.car_id = cars.id
teslamate-1 | * There is a deadlock while migrating (such as using concurrent
teslamate-1 | indexes with a migration_lock)
teslamate-1 |
teslamate-1 | To fix the first issue, run "mix ecto.create" for the desired MIX_ENV.
teslamate-1 |
database-1 | AND BinnedData.speed_bin >= 10
teslamate-1 | To address the second, you can run "mix ecto.drop" followed by
teslamate-1 | "mix ecto.create", both for the desired MIX_ENV. Alternatively you may
teslamate-1 | configure Ecto to use another table and/or repository for managing
teslamate-1 | migrations:
teslamate-1 |
teslamate-1 | config :teslamate, TeslaMate.Repo,
teslamate-1 | migration_source: "some_other_table_for_schema_migrations",
teslamate-1 | migration_repo: AnotherRepoForSchemaMigrations
database-1 | ORDER BY BinnedData.speed_bin DESC;
teslamate-1 |
teslamate-1 | The full error report is shown below.
database-1 |
database-1 |
teslamate-1 |
teslamate-1 | ** (DBConnection.ConnectionError) [Elixir.TeslaMate.Repo] connection not available and request was dropped from queue after 4051ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
database-1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
database-1 |
database-1 | 2026-08-07 15:17:13.518 UTC [1] LOG: starting PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
teslamate-1 |
teslamate-1 | 1. Ensuring your database is available and that you can connect to it
teslamate-1 | 2. Tracking down slow queries and making sure they are running fast enough
database-1 | 2026-08-07 15:17:13.890 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
teslamate-1 | 3. Increasing the pool_size (although this increases resource consumption)
teslamate-1 | 4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
database-1 | 2026-08-07 15:17:13.920 UTC [1] LOG: listening on IPv6 address "::", port 5432
database-1 | 2026-08-07 15:17:14.076 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
teslamate-1 |
teslamate-1 | See DBConnection.start_link/2 for more information
database-1 | 2026-08-07 15:17:21.981 UTC [1] LOG: received fast shutdown request
teslamate-1 |
database-1 | 2026-08-07 15:17:23.959 UTC [32] LOG: database system was interrupted; last known up at 2026-08-02 08:43:29 UTC
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/adapters/sql.ex:1113: Ecto.Adapters.SQL.raise_sql_call_error/1
teslamate-1 | (elixir 1.19.5) lib/enum.ex:1688: Enum."-map/2-lists^map/1-1-"/2
database-1 | 2026-08-07 15:17:41.945 UTC [32] LOG: syncing data directory (fsync), elapsed time: 10.01 s, current path: ./pg_tblspc
database-1 | 2026-08-07 15:17:42.128 UTC [32] LOG: database system was not properly shut down; automatic recovery in progress
database-1 | 2026-08-07 15:17:42.359 UTC [32] LOG: redo starts at 0/4F65BE0
database-1 | 2026-08-07 15:17:42.528 UTC [30] LOG: shutting down
database-1 | 2026-08-07 15:17:44.660 UTC [1] LOG: database system is shut down
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/adapters/sql.ex:1234: Ecto.Adapters.SQL.execute_ddl/4
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:779: Ecto.Migrator.verbose_schema_migration/3
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:563: Ecto.Migrator.lock_for_migrations/4
database-1 |
database-1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
database-1 |
database-1 | 2026-08-07 15:24:42.299 UTC [1] LOG: starting PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:432: Ecto.Migrator.run/4
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:170: Ecto.Migrator.with_repo/3
database-1 | 2026-08-07 15:24:42.347 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
teslamate-1 | nofile:1: (file)
teslamate-1 | 2026-08-07 23:39:02.045 [error] Could not create schema migrations table. This error usually happens due to the following:
teslamate-1 |
teslamate-1 | * The database does not exist
database-1 | 2026-08-07 15:24:42.349 UTC [1] LOG: listening on IPv6 address "::", port 5432
teslamate-1 | * The "schema_migrations" table, which Ecto uses for managing
teslamate-1 | migrations, was defined by another library
database-1 | 2026-08-07 15:24:42.700 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
teslamate-1 | * There is a deadlock while migrating (such as using concurrent
database-1 | 2026-08-07 15:24:45.473 UTC [33] LOG: database system was shut down in recovery at 2026-08-07 15:17:42 UTC
database-1 | 2026-08-07 15:24:45.636 UTC [33] LOG: database system was not properly shut down; automatic recovery in progress
teslamate-1 | indexes with a migration_lock)
teslamate-1 |
database-1 | 2026-08-07 15:24:46.777 UTC [33] LOG: redo starts at 0/4F65BE0
teslamate-1 | To fix the first issue, run "mix ecto.create" for the desired MIX_ENV.
database-1 | 2026-08-07 15:24:46.960 UTC [33] LOG: invalid record length at 0/4F65CE8: expected at least 24, got 0
teslamate-1 |
database-1 | 2026-08-07 15:24:46.966 UTC [33] LOG: redo done at 0/4F65CB0 system usage: CPU: user: 0.02 s, system: 0.03 s, elapsed: 0.36 s
teslamate-1 | To address the second, you can run "mix ecto.drop" followed by
database-1 | 2026-08-07 15:24:48.219 UTC [31] LOG: checkpoint starting: end-of-recovery immediate wait
database-1 | 2026-08-07 15:24:50.455 UTC [31] LOG: checkpoint complete: wrote 0 buffers (0.0%), wrote 3 SLRU buffers; 0 WAL file(s) added, 0 removed, 0 recycled; write=1.634 s, sync=0.070 s, total=2.410 s; sync files=2, longest=0.031 s, average=0.023 s; distance=0 kB, estimate=0 kB; lsn=0/4F65CE8, redo lsn=0/4F65CE8
teslamate-1 | "mix ecto.create", both for the desired MIX_ENV. Alternatively you may
teslamate-1 | configure Ecto to use another table and/or repository for managing
teslamate-1 | migrations:
database-1 | 2026-08-07 15:24:52.469 UTC [1] LOG: database system is ready to accept connections database-1 | 2026-08-07 15:31:40.914 UTC [46] LOG: could not send data to client: Broken pipe
database-1 | 2026-08-07 15:31:40.914 UTC [46] STATEMENT: SELECT t.oid, t.typname, t.typsend, t.typreceive, t.typoutput, t.typinput,
teslamate-1 |
teslamate-1 | config :teslamate, TeslaMate.Repo,
database-1 | coalesce(d.typelem, t.typelem), coalesce(r.rngsubtype, 0), ARRAY (
teslamate-1 | migration_source: "some_other_table_for_schema_migrations",
database-1 | SELECT a.atttypid
teslamate-1 | migration_repo: AnotherRepoForSchemaMigrations
database-1 | FROM pg_attribute AS a
database-1 | WHERE a.attrelid = t.typrelid AND a.attnum > 0 AND NOT a.attisdropped
teslamate-1 |
teslamate-1 | The full error report is shown below.
database-1 | ORDER BY a.attnum
teslamate-1 |
teslamate-1 | ** (DBConnection.ConnectionError) [Elixir.TeslaMate.Repo] connection not available and request was dropped from queue after 4298ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
database-1 | )
database-1 |
teslamate-1 |
teslamate-1 | 1. Ensuring your database is available and that you can connect to it
teslamate-1 | 2. Tracking down slow queries and making sure they are running fast enough
database-1 | FROM pg_type AS t
database-1 | LEFT JOIN pg_type AS d ON t.typbasetype = d.oid
teslamate-1 | 3. Increasing the pool_size (although this increases resource consumption)
teslamate-1 | 4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
teslamate-1 |
teslamate-1 | See DBConnection.start_link/2 for more information
database-1 | LEFT JOIN pg_range AS r ON r.rngtypid = t.oid OR r.rngmultitypid = t.oid OR (t.typbasetype <> 0 AND r.rngtypid = t.typbasetype)
teslamate-1 |
database-1 | WHERE (t.typrelid = 0)
database-1 | AND (t.typelem = 0 OR NOT EXISTS (SELECT 1 FROM pg_catalog.pg_type s WHERE s.typrelid != 0 AND s.oid = t.typelem))
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/adapters/sql.ex:1113: Ecto.Adapters.SQL.raise_sql_call_error/1
database-1 |
teslamate-1 | (elixir 1.19.5) lib/enum.ex:1688: Enum."-map/2-lists^map/1-1-"/2
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/adapters/sql.ex:1234: Ecto.Adapters.SQL.execute_ddl/4
database-1 |
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:779: Ecto.Migrator.verbose_schema_migration/3
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:563: Ecto.Migrator.lock_for_migrations/4
database-1 | 2026-08-07 15:31:40.936 UTC [46] FATAL: connection to client lost
database-1 | 2026-08-07 15:31:40.936 UTC [46] STATEMENT: SELECT t.oid, t.typname, t.typsend, t.typreceive, t.typoutput, t.typinput,
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:432: Ecto.Migrator.run/4
database-1 | coalesce(d.typelem, t.typelem), coalesce(r.rngsubtype, 0), ARRAY (
teslamate-1 | (ecto_sql 3.13.5) lib/ecto/migrator.ex:170: Ecto.Migrator.with_repo/3
teslamate-1 | nofile:1: (file)
database-1 | SELECT a.atttypid
database-1 | FROM pg_attribute AS a
database-1 | WHERE a.attrelid = t.typrelid AND a.attnum > 0 AND NOT a.attisdropped
database-1 | ORDER BY a.attnum
database-1 | )
database-1 |
database-1 | FROM pg_type AS t
database-1 | LEFT JOIN pg_type AS d ON t.typbasetype = d.oid
database-1 | LEFT JOIN pg_range AS r ON r.rngtypid = t.oid OR r.rngmultitypid = t.oid OR (t.typbasetype <> 0 AND r.rngtypid = t.typbasetype)
database-1 | WHERE (t.typrelid = 0)
database-1 | AND (t.typelem = 0 OR NOT EXISTS (SELECT 1 FROM pg_catalog.pg_type s WHERE s.typrelid != 0 AND s.oid = t.typelem))
database-1 |
database-1 |

JakobLichterfeld Aug 7, 2026
Maintainer

Thanks for the logs — this is not an Alpine issue, and your data is most likely fine.

What the database log actually says:

15:17:23 database system was interrupted; last known up at 2026-08-02 08:43:29 UTC
15:17:41 syncing data directory (fsync), elapsed time: 10.01 s
15:17:21 received fast shutdown request          <-- stopped mid-recovery
15:17:42 database system was not properly shut down; automatic recovery in progress
15:17:44 database system is shut down            <-- recovery aborted

15:24:42 (second start)
15:24:46 redo starts at 0/4F65BE0
15:24:46 invalid record length at 0/4F65CE8      <-- normal: this is the end of the WAL
15:24:46 redo done at 0/4F65CB0
15:24:52 database system is ready to accept connections

So:

The poweroff while Docker was running left PostgreSQL in an unclean state, so it has to run crash recovery on the next start. On your hardware that takes a while (the fsync of the data directory alone took 10 s).
On the first start the container was stopped again after 8 seconds, during recovery. On the second attempt recovery completed successfully — the database is up and consistent. invalid record length at the very last LSN is the expected way redo ends, not corruption.
All the TeslaMate errors (connection not available and request was dropped from queue after 4862ms, Could not create schema migrations table) are just consequences: TeslaMate tries to run migrations while PostgreSQL is still recovering, gives up after ~5 s, and gets restarted by restart: always (in your docker-compose.yml file). That is the "container keeps restarting" you saw. Nothing is wrong with the schema.

What I would do now:

Take a backup while the database is up, before anything else, See https://docs.teslamate.org/docs/maintenance/backup
Don't stop the stack while recovery is in progress. After an unclean shutdown, let database finish (watch docker compose logs -f database until you see database system is ready to accept connections) — TeslaMate will then start fine on its next restart.
Avoid the unclean shutdown in the first place. Run docker compose down before poweroff (on Alpine/OpenRC stopping the docker service does not necessarily stop the containers gracefully).

Optional, to stop the restart loop on every boot: add a healthcheck to database and let teslamate depend on it:

database:
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -U teslamate"]
    interval: 10s
    timeout: 5s
    retries: 30
teslamate:
  depends_on:
    database:
      condition: service_healthy

For the record on the title: the TeslaMate images are debian:trixie-slim based (AMD64/ARM64) — Alpine as the host OS is fine, we just don't ship Alpine-based images.

🤖 Comment drafted with Claude Code (Opus 5 high) — sponsored by Claude for Open Source

Answer selected by JakobLichterfeld

HanwGu Aug 8, 2026
Author

Thanks.👍 I run the teslamate successfully with all history data. 🥳And the "docker compose down" is very important.
Best wishes to you.

JakobLichterfeld Aug 8, 2026
Maintainer

Awesome to hear it works again. Enjoy your data collection.

Navigation Menu

Uh oh!

Restart loop / "Could not create schema migrations table" after unclean shutdown (PostgreSQL still in crash recovery) #5591

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 4 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

Restart loop / "Could not create schema migrations table" after unclean shutdown (PostgreSQL still in crash recovery) #5591

Uh oh!

HanwGu Aug 7, 2026

Replies: 1 comment · 4 replies

Uh oh!

JakobLichterfeld Aug 7, 2026 Maintainer

Uh oh!

Uh oh!

HanwGu Aug 7, 2026 Author

Uh oh!

Uh oh!

JakobLichterfeld Aug 7, 2026 Maintainer

Uh oh!

HanwGu Aug 8, 2026 Author

Uh oh!

JakobLichterfeld Aug 8, 2026 Maintainer

HanwGu
Aug 7, 2026

Replies: 1 comment 4 replies

JakobLichterfeld
Aug 7, 2026
Maintainer

HanwGu Aug 7, 2026
Author

JakobLichterfeld Aug 7, 2026
Maintainer

HanwGu Aug 8, 2026
Author

JakobLichterfeld Aug 8, 2026
Maintainer