starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

LastInsertId is not supported by Postgres #635

New Issue
Closed
opened 2025-12-29 02:21:26 +01:00 by adam · 1 comment
adam commented 2025-12-29 02:21:26 +01:00
Owner
Copy Link

Originally created by @MichaelSasser on GitHub (Feb 15, 2024).

Bug description

Hi, I've tried to update to the v0.23 release and I received the following error:

{"level":"fatal","error":"LastInsertId is not supported by this driver","time":1708000343,"message":"Migration failed: LastInsertId is not supported by this driver"}

Just to make sure, I've updated Postgres to the latest 16.x version, but I'm still receiving this error message.

I'm not certain what LastInsertId should do, I'm guessing it should return the latest used sequential number on INSERT? Since it doesn't seem supported by Postgres, I would maybe suggest looking into RETURNING (see PostgreSQL - INSERT) if there is no simpler workaround.

The optional RETURNING clause causes INSERT to compute and return value(s) based on each row actually inserted [...]. This is primarily useful for obtaining values that were supplied by defaults, such as a serial sequence number.

Environment

  • Version of headscale used: headscale/headscale:0.23.0; Postgres 15.x and 16.x
  • Headscale is behind a (reverse) proxy (envoyproxy/envoy:v1.29.1)
  • Headscale runs in a container

To Reproduce

  1. Have an existing (working) installation using PostgreSQL
  2. Update the config to accommodate for the breaking changes (db_* -> database.postgres.*) and set the database to postgres again.
  3. Update the command in docker from ´headscale servetoserve`
  4. Deploy the new version
  5. See error messages in logs

Logs and attachments

(Headscale doesn't start)

Host Headscale

  • Linux acme 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux
  • Docker version 25.0.1, build 29cf629
ID    NAME    CORES   CPU TYPE    ARCHITECTURE   MEMORY     DISK     STORAGE TYPE   TRAFFIC
1     cx11    1       shared      x86            2.0 GB     20 GB    local          20 TB

Host Postgres

  • Linux pg01 6.1.0-17-arm64 #1 SMP Debian 6.1.69-1 (2023-12-30) aarch64 GNU/Linux
  • Docker version 25.0.1, build 29cf629
ID    NAME    CORES   CPU TYPE    ARCHITECTURE   MEMORY     DISK     STORAGE TYPE   TRAFFIC
93    cax21   4       shared      arm            8.0 GB     80 GB    local          20 TB
Originally created by @MichaelSasser on GitHub (Feb 15, 2024). ## Bug description Hi, I've tried to update to the v0.23 release and I received the following error: ```log {"level":"fatal","error":"LastInsertId is not supported by this driver","time":1708000343,"message":"Migration failed: LastInsertId is not supported by this driver"} ``` Just to make sure, I've updated Postgres to the latest 16.x version, but I'm still receiving this error message. I'm not certain what `LastInsertId` should do, I'm guessing it should return the latest used sequential number on `INSERT`? Since it doesn't seem supported by Postgres, I would maybe suggest looking into `RETURNING` (see [PostgreSQL - INSERT](https://www.postgresql.org/docs/16/sql-insert.html)) if there is no simpler workaround. > The optional `RETURNING` clause causes `INSERT` to compute and return value(s) based on each row actually inserted [...]. This is primarily useful for obtaining values that were supplied by defaults, such as a serial sequence number. ## Environment - Version of headscale used: `headscale/headscale:0.23.0`; Postgres 15.x and 16.x - [x] Headscale is behind a (reverse) proxy (`envoyproxy/envoy:v1.29.1`) - [x] Headscale runs in a container ## To Reproduce 1. Have an existing (working) installation using PostgreSQL 2. Update the config to accommodate for the breaking changes (`db_*` -> `database.postgres.*`) and set the database to `postgres` again. 3. Update the command in docker from ´headscale serve` to `serve` 4. Deploy the new version 5. See error messages in logs ## Logs and attachments (Headscale doesn't start) ### Host Headscale - `Linux acme 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux` - `Docker version 25.0.1, build 29cf629` ```plain ID NAME CORES CPU TYPE ARCHITECTURE MEMORY DISK STORAGE TYPE TRAFFIC 1 cx11 1 shared x86 2.0 GB 20 GB local 20 TB ``` ### Host Postgres - `Linux pg01 6.1.0-17-arm64 #1 SMP Debian 6.1.69-1 (2023-12-30) aarch64 GNU/Linux` - `Docker version 25.0.1, build 29cf629` ```plain ID NAME CORES CPU TYPE ARCHITECTURE MEMORY DISK STORAGE TYPE TRAFFIC 93 cax21 4 shared arm 8.0 GB 80 GB local 20 TB ```
adam added the bug label 2025-12-29 02:21:26 +01:00
adam closed this issue 2025-12-29 02:21:26 +01:00
adam commented 2025-12-29 02:21:26 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 15, 2024):

This seem to be a regression in Gorm: https://github.com/go-gorm/gorm/issues/6812

Also tracking issue in the migration framework: https://github.com/go-gormigrate/gormigrate/issues/217

I'm rolling back the versions for now in a PR.

@kradalby commented on GitHub (Feb 15, 2024): This seem to be a regression in Gorm: https://github.com/go-gorm/gorm/issues/6812 Also tracking issue in the migration framework: https://github.com/go-gormigrate/gormigrate/issues/217 I'm rolling back the versions for now in a PR.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#635
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?