mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-13 06:32:03 +00:00
Marc-André Bombeck
e64435f6a5
The column was INTEGER. A single object may occupy 8 MiB across 10 000 multipart parts, which is the 80 GB the uploader explicitly permits, and Postgres INTEGER stops at 2.1 GB. An account between the two uploads fine and then cannot be recorded, so the biggest account on the host is the one the console would have to report on and could not. BIGINT in the table, BigInt in the model, Number() where the route builds the wire row so the payload type stays a plain number. The migration is edited in place rather than followed by a second one: the table has not shipped, and a column widened before its first release is one column, not a history. The comparison with the in-database backup does not carry over, for the record: that size is octet_length over a bytea Postgres caps at 1 GB, while this object never touches the database at all.
20 lines
869 B
SQL
20 lines
869 B
SQL
-- One row per account, written by the nightly off-host backup job when an
|
|
-- object lands in the bucket. The admin console reads it to say, per account,
|
|
-- whether the newest off-host copy is as fresh as the schedule promises,
|
|
-- without the page ever talking to the bucket.
|
|
CREATE TABLE "offhost_backup_state" (
|
|
"user_id" TEXT NOT NULL,
|
|
"last_success_at" TIMESTAMP(3) NOT NULL,
|
|
-- BIGINT, not INTEGER: a single object may occupy 8 MiB x 10 000 multipart
|
|
-- parts, so the uploader permits 80 GB and a 32-bit column would refuse
|
|
-- every account past 2.1 GB.
|
|
"size_bytes" BIGINT NOT NULL,
|
|
|
|
CONSTRAINT "offhost_backup_state_pkey" PRIMARY KEY ("user_id")
|
|
);
|
|
|
|
ALTER TABLE "offhost_backup_state"
|
|
ADD CONSTRAINT "offhost_backup_state_user_id_fkey"
|
|
FOREIGN KEY ("user_id") REFERENCES "users"("id")
|
|
ON DELETE CASCADE ON UPDATE CASCADE;
|