diff --git a/docs/FOX_Checklist.pdf b/docs/FOX_Checklist.pdf index deac68d..068ad53 100644 Binary files a/docs/FOX_Checklist.pdf and b/docs/FOX_Checklist.pdf differ diff --git a/docs/FOX_Feature_Implemented.html b/docs/FOX_Feature_Implemented.html index 409083a..5a71db0 100644 --- a/docs/FOX_Feature_Implemented.html +++ b/docs/FOX_Feature_Implemented.html @@ -119,6 +119,7 @@

Change log

Newest first. Every change to FoxByte adds a row here.

+ diff --git a/docs/FOX_Feature_Implemented.pdf b/docs/FOX_Feature_Implemented.pdf index ae27ed0..9da2062 100644 Binary files a/docs/FOX_Feature_Implemented.pdf and b/docs/FOX_Feature_Implemented.pdf differ diff --git a/enterprise/masking/sql.go b/enterprise/masking/sql.go index af38df4..394eccc 100644 --- a/enterprise/masking/sql.go +++ b/enterprise/masking/sql.go @@ -350,13 +350,19 @@ func rekeyTable(schema, table string, cols []branch.MaskColumn, rules []branch.M rk.Start = append(rk.Start, nw.shadowDDL(nm.next)...) rk.Start = append(rk.Start, keepFn(nm.fn, []target{{nm.shadow, old}, {nm.next, nw}})...) rk.Fill = nw.fill(nm.next) - rk.Swap = append(writesWait(nm), + // The view is replaced first, to read the new shadow, and keeps its grants. + // A masked read locks the view, then the table and the shadow it reads; + // the swap takes them in that order too. Renaming the shadow first held it + // while the view was still to be taken, and a read that had taken the view + // in between waited for the shadow: a deadlock, and the read failed. A view + // holds its tables by oid, so it reads the new shadow under its next name + // and under the shadow's name once renamed. + inNext := nm + inNext.shadow = nm.next + rk.Swap = append(writesWait(nm), viewSQL(inNext, cols, nw.own, nw.shadow, nw.k(), true)[0], "ALTER TABLE "+nm.shadow+" RENAME TO "+ident(nm.shadowName+"__old"), "ALTER TABLE "+nm.next+" RENAME TO "+ident(nm.shadowName), ) - // The view now reads the new shadow (by its name, now the shadow's), and - // keeps its grants. - rk.Swap = append(rk.Swap, viewSQL(nm, cols, nw.own, nw.shadow, nw.k(), true)[0]) rk.Swap = append(rk.Swap, keepFn(nm.fn, []target{{nm.shadow, nw}})...) rk.Swap = append(rk.Swap, "DROP TABLE "+branch.MaskSchema+"."+ident(nm.shadowName+"__old")) return rk, true, nil diff --git a/enterprise/masking/sql_test.go b/enterprise/masking/sql_test.go index eb130bc..c9e11c3 100644 --- a/enterprise/masking/sql_test.go +++ b/enterprise/masking/sql_test.go @@ -207,8 +207,14 @@ func TestRekeyTable(t *testing.T) { if strings.Contains(swap, "'default'") || strings.Contains(swap, "__next\" (") || strings.Contains(swap, "GRANT") { t.Errorf("after the swap the triggers keep only the new shadow, under the new key, and grants are kept:\n%s", swap) } - if i, j := strings.Index(swap, "RENAME TO \"public__customers\""), strings.Index(swap, "CREATE OR REPLACE VIEW"); i < 0 || j < i { - t.Errorf("the view is replaced before the new shadow has the shadow's name:\n%s", swap) + // The swap locks what a masked read locks, in a read's order: the view + // before the shadow. The other way round, a read arriving between the two + // deadlocked with it. + if rk.Swap[2] != strings.Split(swap, ";\n")[2] || !strings.HasPrefix(rk.Swap[2], `CREATE OR REPLACE VIEW bb_mask."customers"`) { + t.Errorf("the swap does not take the view first, after holding writes:\n%s", swap) + } + if !strings.Contains(rk.Swap[2], `JOIN bb_mask."public__customers__next" m ON`) { + t.Errorf("the view does not read the new shadow:\n%s", rk.Swap[2]) } }
DateFeature(s)What changedCommit / PR
11 Nov 2026O3Fixed: a masked account’s read could deadlock with a key rotation. Swapping a table’s new masks in renamed the old shadow table first and replaced the masked view after it, while a masked read locks the view first, then the table and the shadow: a read arriving between the two held the view and waited for the shadow the swap held, the swap waited for the view, and Postgres ended one of them (seen once in the integration suite: four failed reads during fox mask key rotate). The swap now replaces the view first, reading the new shadow by oid, then renames, in a read’s order, so a read arriving mid-swap waits a moment and reads the new masks. Shown on PostgreSQL 18 with the swap paused at the point between: the old order deadlocked, the new one did not, and the view then reads the new shadow under its own name. Tests: integration 936/936, integration-f5 57/57, Go unit tests in both editions (the swap takes the view first), vet for macOS, Linux and Windows.fix/mask-rotate-deadlock
11 Nov 2026H1Fixed: every branch start wrote 82 entries into the branch’s Blackbox. Since #221, each start of a branch takes dblink away from clients again (a REVOKE of EXECUTE on each of its 41 functions, from PUBLIC and from db_client), and the Blackbox records every REVOKE, held or not: a restarted branch gained 82 entries with no actor, and a branch made from just before an entry held 82 entries made after it. Each REVOKE is now issued only while the grant it removes is there, so a start that changes nothing records nothing, and a grant someone added is still taken away, and recorded, on the next start. Tests: integration-v2 403/403 (it was 401/403 on main), integration 936/936, Go unit tests in both editions (the REVOKEs are guarded by a look at the grant), vet for macOS, Linux and Windows; on the test VM a branch’s restart added 0 entries, and one given two dblink grants lost both on restart and recorded those two REVOKEs.fix/v2-branch-ledger
11 Nov 2026(tests)Fixed: two unit tests that failed CI now and then. TestSnapshotServesThePreviousAnswerRatherThanHang ended with its deliberately hung read still running; let go as the test ended, the read looked at the test’s clock while the test’s cleanup put the real one back, and go test -race in CI failed on PRs that had not touched it (2 runs in 300). The test now lets the read finish before that cleanup. TestWitnessAnswersOneQuestion freed a port by closing a listener and took it for a primary that is down, but the test servers it then started were sometimes handed that very port, so the “down” primary answered; it now uses port 0, where nothing can listen. Nothing outside the tests changed. Tests: the test 1000 times under the race detector, internal/branch 20 times, the console’s and the Gateway’s snapshot tests 10 times, the witness test 500 times on macOS and Linux, all clean.fix/snapshot-test-race
11 Nov 2026L4Table dialogs (point 12.3, second part, pgAdmin’s basics). + New table… in the Console’s schema rail makes a table with its columns and primary key, and opens on them. A table’s Structure tab lists its columns from the catalog with + Add column…, Edit… (name, type with a USING conversion, NOT NULL, default; only what changed, in one transaction, the rename last) and Drop…, and renames and drops the table; its Constraints tab adds, edits, renames and drops primary, unique, foreign and check keys: columns in the order picked, a foreign key’s referenced table with its primary key filled in, ON DELETE and ON UPDATE, deferrable; an edit replaces the key in one statement under its name and keeps MATCH FULL, NOT VALID and NO INHERIT; a key with parts the dialog cannot write again (INCLUDE, NULLS NOT DISTINCT, an exclusion, an inherited one) is renamed and dropped but not edited. Each dialog shows its SQL and runs it as the person; DROP TABLE meets the guardrail, and Put it in the editor is the way to override it. The engine gives each constraint’s parts (key) on GET …/schema/table/{oid}. Tests: integration 936/936 (§11aq new: what each dialog writes run; a failed rename leaving a column edit undone; each key’s parts, in the key’s order; a key replaced under its name, a failed replacement keeping it, one depended on refused; keys not offered as edits; DROP TABLE refused by the guardrail, then dropped with the override), UI 61/61 plus the upgrade test (a table made, its columns added, edited and dropped, renamed, its drop refused and put in the editor; its four kinds of key added, a foreign key edited, a check renamed and dropped; a refusal shown in the dialog), integration-f5 57/57, f1 70/70, f6 71/71, web unit 294/294, Go unit tests in both editions, vet for macOS, Linux and Windows. v2 401/403: its two failures (a point-in-time branch’s Blackbox holding 82 entries from after the entry it was made before, and a branch’s restart adding them again) are the same on main without this change.feat/p12-tables