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

Aperta
  • Qualcosa non va?
#135 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
kotlin, postgresql
Ambito
databases

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Kotlin
Stelle
14
Fork
0
Merge medio
9h 54m
PR unite (30g)
11

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di softwaremill/okapi

Tutte le issue di softwaremill/okapi

Issue simili

Altre issue su Kotlin

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.