Postgres: TIMESTAMP WITHOUT TIME ZONE + java.sql.Timestamp stores JVM-local time; mixed-TZ fleets/DST corrupt ordering, lag, purge

Offen
  • Stimmt etwas nicht?
#135 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
kotlin, postgresql
Bereich
databases

Rechercherichtung

Start with PostgresOutboxStore, which binds created_at, updated_at and last_attempt with setTimestamp and reads them back with getTimestamp, and with the Postgres schema changesets that declare these columns as TIMESTAMP. Add a migration that converts the columns to timestamptz, then switch the store to OffsetDateTime binding and reading. Done when a test passes with a non-UTC TimeZone.setDefault and the migration path for existing users is documented.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

breaking-change bug

Severity: Medium · Area: okapi-postgres schema and JDBC mapping · Found in: code review of main @ e5630a1 (reasoned from pgjdbc semantics, not reproduced)

Problem

The Postgres schema declares created_at, updated_at and last_attempt as TIMESTAMP (without time zone). PostgresOutboxStore writes them with setTimestamp(Timestamp.from(instant)) and reads them with getTimestamp(...).toInstant(). pgjdbc renders a java.sql.Timestamp in the JVM default time zone, so the column stores local wall-clock time of whichever JVM wrote the row:

  • Mixed-TZ fleets (e.g. one pod with TZ=Europe/Warsaw, others UTC, or a developer laptop pointed at a shared DB):
    • ORDER BY created_at is skewed by hours
    • the lag gauge (okapi.entries.lag.seconds) is off by hours, possibly negative
    • the purger's last_attempt < cutoff deletes DELIVERED rows hours early or keeps them hours late
  • DST fall-back in a non-UTC zone: an hour of local times repeats, so two different instants map to the same stored value. Ordering and lag are wrong for that hour, and reading back can shift values by 1 h.

MySQL TIMESTAMP(6) normalizes to UTC, so this mainly affects Postgres.

Suggested fix

Migrate the columns to TIMESTAMPTZ (changeset 002 with ALTER COLUMN ... TYPE timestamptz USING ... AT TIME ZONE '<zone that wrote the data>', documented for existing users). Bind with setObject(i, instant.atOffset(ZoneOffset.UTC)) and read with getObject(col, OffsetDateTime::class.java). Add a test that runs the store with a non-UTC TimeZone.setDefault.

Vorherrschende Sprache
Kotlin
Sterne
14
Forks
0
Ø Merge
9 Std. 54 Min.
Gemergte PRs (30 T.)
11

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus softwaremill/okapi

Alle Issues in softwaremill/okapi

Ähnliche Issues

Weitere Issues zu Kotlin

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.