admin
9c69b3ff07
gates / gates (push) Successful in 27s
Evidence off the machine at the end of the phases that produced it (R-320). Teardown follows. PHASE 2 — the two database engines, through the REAL Update button: - MariaDB 11.6 -> 12.3 on nextcloud: PROVEN, and pressed through the button for the first time. All four SPIKE-r459 observables: the datadir's own record moved 11.6.2 -> 12.3.3; the engine itself says "already upgraded ... no need to run mariadb-upgrade again"; the entrypoint says "Major version upgrade detected ... Check required!" and then STARTED and FINISHED it (not the `skipped due to $MARIADB_AUTO_UPGRADE` line R-459 feared); and the engine took its own pre-upgrade backup, 631 905 B. The seeded Nextcloud account read back. - PostgreSQL 16 -> 17 on docmost: FAILED exactly as R-463 predicted and nobody had measured. 5.1 s to held; the pin named 17 while nothing ran; the restore brought it back in 29.1 s. The engine's REFUSAL LINE was destroyed by failAndHold before any probe could read it, so it was REPRODUCED INDEPENDENTLY with a control on every step (R-320). PHASE 3 — the bad days. B1 produced THE UNATTENDED HOLD, which this project has never had: the caller pressed once with nobody watching, the app held after 312.9 s, and passes 2 and 3 pressed nothing. B2 put the pin back on a pull failure in 1.0 s. B3 refused `busy` six times. B4 showed there is NO single-flight — 5 of 5 updates ran at once and all ended honest. B5 cut the power in `backing-up` and the box recovered itself and said so. B7 refused under the 2 GB floor. B9 found R-458's risk narrower than the row states. PHASE 4 — every badge on the box is TRUE, and the held app answers all four of Q4's questions. FINDINGS, five new and three corrections to existing rows. The one that matters: R-618 is P1 — two templates name a health probe the app does not answer, and because the guarded update waits on that same probe, a SUCCESSFUL update ends by STOPPING a working app. Measured: tandoor served HTTP 200 on the new version at four samples across five minutes and was then stopped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
52 lines
2.7 KiB
Plaintext
52 lines
2.7 KiB
Plaintext
*** THIS FILE IS THE FIRST ATTEMPT AND ITS MAIN RESULT IS WRONG — KEPT DELIBERATELY. ***
|
|
|
|
The volume lookup returned EMPTY, so the copy was empty, so postgres:17 initialised a FRESH 17
|
|
datadir and started happily. The line "PG_VERSION on the copy:" two lines below is blank and that
|
|
should have stopped the step; it did not. `17-...` is therefore NOT evidence that 17 accepts a 16
|
|
datadir — it never met one.
|
|
|
|
WHAT IT DID ACCIDENTALLY MEASURE, and this part IS real and useful: the MIRROR case. postgres:16
|
|
meeting a datadir written by 17 refuses in its own words —
|
|
|
|
FATAL: database files are incompatible with server
|
|
DETAIL: The data directory was initialized by PostgreSQL version 17, which is not compatible
|
|
with this version 16.15.
|
|
|
|
which is the sentence a household would meet if a 17 pin were ever put BACK to 16. The correct
|
|
measurement — 17 meeting 16 — is in `18-postgres-refusal-reproduced.txt`.
|
|
|
|
================================================================================================
|
|
|
|
INDEPENDENT REPRODUCTION of the PostgreSQL 16 -> 17 refusal
|
|
R-320: the product destroyed the original evidence (R-621), so it is reproduced here rather
|
|
than inferred. Plain docker, beside the product, on a COPY of a real 16 datadir.
|
|
|
|
the live docmost 16 datadir volume:
|
|
PG_VERSION on the copy:
|
|
|
|
=== now start postgres:17-alpine on that 16 datadir — the household's case, exactly
|
|
--- container state:
|
|
running=true exit=0 restarts=0
|
|
--- THE REFUSAL, VERBATIM:
|
|
2026-09-21 19:45:47.148 UTC [41] LOG: database system is shut down
|
|
done
|
|
server stopped
|
|
|
|
PostgreSQL init process complete; ready for start up.
|
|
|
|
2026-09-21 19:45:47.239 UTC [1] LOG: starting PostgreSQL 17.11 on x86_64-pc-linux-musl, compiled by gcc (Alpine 15.2.0) 15.2.0, 64-bit
|
|
2026-09-21 19:45:47.239 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
|
|
2026-09-21 19:45:47.239 UTC [1] LOG: listening on IPv6 address "::", port 5432
|
|
2026-09-21 19:45:47.245 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
|
|
2026-09-21 19:45:47.253 UTC [55] LOG: database system was shut down at 2026-09-21 19:45:47 UTC
|
|
2026-09-21 19:45:47.263 UTC [1] LOG: database system is ready to accept connections
|
|
|
|
--- positive control: the SAME copy under postgres:16-alpine must start
|
|
running=false exit=1
|
|
|
|
2026-09-21 19:45:53.852 UTC [1] FATAL: database files are incompatible with server
|
|
2026-09-21 19:45:53.852 UTC [1] DETAIL: The data directory was initialized by PostgreSQL version 17, which is not compatible with this version 16.15.
|
|
--- and the data is still there, asked of the engine:
|
|
Error response from daemon: container ea0332381c9771265f47fd08988836c38afb697496096074305ed154a3ac8f3e is not running
|
|
(throwaway containers and the copied volume removed by name)
|