From a42d4083fa5a8a7f1aff9192be90b97f0c098a1c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Thu, 3 Sep 2026 05:47:14 +0200 Subject: [PATCH 1/2] docs(changelog): correct the v1.38.5 backup claim The entry said the weekly pass finishes again. It was written from a measurement taken on a development machine with a multi-gigabyte heap, and it does not hold on a small container: capped at 1 GB the runtime gets a 524 MB heap, and the pass still runs out of memory there. It gets roughly three times further than before, which is a real improvement and is now described as one, but it does not complete, and the failure takes the whole process down rather than failing as a job. Building the record incrementally instead of whole is the fix and has not landed. Until it does, an instance backing up a large record needs more than 1 GB, and the entry says so. --- CHANGELOG.md | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 9e2f49316..36d02615d 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,8 +2,9 @@ ## [1.38.5] — 2026-09-03 -The weekly backup finishes again, the dashboard stops scanning the two -largest tables, and several settings now do what they say. +The weekly backup costs a fraction of the memory it did, the dashboard +stops scanning the two largest tables, and several settings now do what +they say. ### Security @@ -27,10 +28,20 @@ largest tables, and several settings now do what they say. which is four full copies of the record at the same moment. The stored copy is now compressed before it is encrypted, which takes an order of magnitude off everything after it, and the pass releases each stage before allocating - the next. A seeded 445 000-reading account went from dying of memory to - finishing in about twenty seconds, with a stored copy of 25 MB instead of - 322 MB. The pass also has an explicit two-hour window now, so a genuinely - slow disk cannot be mistaken for a broken run. The nightly off-host copy is + the next. A seeded 445 000-reading account, on a machine with + a generous heap, went from dying of memory to finishing in about twenty + seconds, with a stored copy of 25 MB instead of 322 MB. The pass also has an + explicit two-hour window now, so a genuinely slow disk cannot be mistaken for + a broken run. + + **That measurement does not carry to a small container, and this entry + originally over-claimed from it.** A container capped at 1 GB gives the + runtime a 524 MB heap, and against one of those the pass still runs out of + memory, roughly three times further along than before but short of the end. + Worse, it takes the whole process down with it, so a failed backup becomes an + outage for everyone else on the instance. Building the record incrementally + rather than whole is the actual fix and has not landed yet. Until it does, an + instance backing up a large record wants more than 1 GB. The nightly off-host copy is built the same way and got the same treatment; files written before this still restore, and so do backups already sitting in the database. - **A failed backup run is now visible on the backups page.** The weekly pass From 50a88a9526224b7628987d0af8b2170848967aa0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Thu, 3 Sep 2026 05:55:54 +0200 Subject: [PATCH 2/2] style: reflow the corrected v1.38.5 backup entry The correction was inserted mid-bullet, which left the off-host sentence trailing after it and the paragraph unwrapped. The off-host sentence goes back with the technical description it belongs to, and the correction reads last. --- CHANGELOG.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 36d02615d..0fa6f0cbb 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -32,7 +32,9 @@ they say. a generous heap, went from dying of memory to finishing in about twenty seconds, with a stored copy of 25 MB instead of 322 MB. The pass also has an explicit two-hour window now, so a genuinely slow disk cannot be mistaken for - a broken run. + a broken run. The nightly off-host copy is built the same way and got the + same treatment; files written before this still restore, and so do backups + already sitting in the database. **That measurement does not carry to a small container, and this entry originally over-claimed from it.** A container capped at 1 GB gives the @@ -41,9 +43,8 @@ they say. Worse, it takes the whole process down with it, so a failed backup becomes an outage for everyone else on the instance. Building the record incrementally rather than whole is the actual fix and has not landed yet. Until it does, an - instance backing up a large record wants more than 1 GB. The nightly off-host copy is - built the same way and got the same treatment; files written before this - still restore, and so do backups already sitting in the database. + instance backing up a large record wants more than 1 GB. + - **A failed backup run is now visible on the backups page.** The weekly pass can stop and leave no trace: the page listed whatever copies existed, and a copy from six weeks ago carries a timestamp exactly like Sunday's. The page