You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e9cb25b
Browse filesBrowse the repository at this point in the historyBrowse files
feat: report rows in DEFAULT that no maintenance run would reach (#94)
* feat: report rows in DEFAULT that no maintenance run would reach
A row written with a key outside every partition after adoption lands
in DEFAULT, and if its window is behind the cursor nothing ever comes
back for it: no apply creates that window again, retention cannot drop
it, and plan said there was nothing to do. Outpost's publish API takes
a client-supplied time, which is how its maintainer found it.
plan now reports it as rows_in_default (WARNING), so plan --check exits
3 and apply carries it in result.issues; backfill moves the rows into a
partition of their own. The earliest row in DEFAULT decides, read with
the index probe partition_data already uses: rows of a window the same
plan creates are left to its attach, and rows ahead of the cursor to
the run that reaches them. ActualTree.default_earliest carries it.
* test: a past window the plan names is left to its attach
---------
Co-authored-by: Alexey Shalaev <shalaevad.alexey@gmail.com>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+16Lines changed: 16 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,22 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
12
12
13
13
* a backfilled window always attaches with writers held at the parent ([#89](https://github.com/bedrock-python/pg-partsmith/issues/89)) ([b1260c1](https://github.com/bedrock-python/pg-partsmith/commit/b1260c1a8bcdd6388c3836d57eb548f8fe5959bb))
14
14
15
+
## 1.8.0 — rows in DEFAULT that no run would reach are reported
16
+
17
+
An application that writes its own key values can put a row into DEFAULT after the table
18
+
was adopted: an event dated last year lands there because no partition covers it. Creation
19
+
walks forward from the cursor, so nothing ever came back for it. `plan` said there was
20
+
nothing to do, `plan --check` exited 0, and retention could not drop what was never in a
21
+
partition. Found by Outpost's maintainer: its publish API accepts a client-supplied `time`.
22
+
23
+
`plan` now reports such rows as `rows_in_default`, a WARNING, so `plan --check` exits 3 and
24
+
`apply` carries it in `result.issues`; `backfill` moves them into a partition of their own.
25
+
What decides is the earliest row in DEFAULT: one in a window the same plan creates is moved
26
+
by its attach, and one dated ahead of the cursor by the run that gets there, so neither is
27
+
reported. During an adoption the history waiting for `backfill` is reported the same way,
28
+
until it has moved. `ActualTree.default_earliest` carries the earliest key, read with the
29
+
same index probe `partition_data` uses.
30
+
15
31
## 1.7.2 — a backfill's last attach no longer rejects a live insert
16
32
17
33
The attach that ends a backfilled window is documented to hold writers at the parent, and
Copy file name to clipboardExpand all lines: docs/guide/troubleshooting.md
+15Lines changed: 15 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -113,6 +113,21 @@ backfill back to the window. Run `backfill`: once DEFAULT is drained it looks fo
113
113
these tables and attaches them. Only a table whose name is the one the scheme gives that
114
114
window under this root counts — its rows are never read otherwise.
115
115
116
+
## `rows_in_default` — rows no maintenance run will reach
117
+
118
+
```text
119
+
[warning] rows_in_default: public.events_default holds rows of 2025_06, a window behind the cursor that no partition of public.events covers, so no maintenance run will reach them, retention included; backfill (partition_data) moves them into partitions of their own.
120
+
```
121
+
122
+
Creation walks forward from the cursor, so a row in DEFAULT from a window before it stays
123
+
there: no `apply` creates that window again, and retention, which drops partitions, never
124
+
sees it. Two ways to get there: an adoption whose history `backfill` has not moved yet, and
125
+
an application that writes its own key values — an event dated last year, say — after the
126
+
table was adopted. Run `backfill`; it creates the window's partition and moves the rows,
127
+
and retention then treats that partition like any other. The finding names the earliest such
128
+
window. Rows of a window the same plan creates are left to its attach, and rows dated ahead
129
+
of the cursor to the run that reaches them, so neither is reported.
130
+
116
131
## `grace_pending`, `drop_deferred` (INFO)
117
132
118
133
A detached orphan waiting out its grace period, or one whose `DropAfter(when=…)`
Copy file name to clipboardExpand all lines: docs/reference/findings.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,6 +31,7 @@ issues too, with the exception's name in front of the message.
31
31
|`grace_pending`| INFO | A detached orphan still within its grace period. | Nothing. |
32
32
|`drop_deferred`| INFO | An orphan past its grace whose drop condition does not hold yet. | Nothing. |
33
33
|`unattached_rows`| WARNING | A table under a window's partition name holds rows but was never attached — a fill that stopped before its attach — so no query through the root sees them. | Run `backfill` (`partition_data`); it attaches the table. |
34
+
|`rows_in_default`| WARNING | The root's DEFAULT partition holds rows of a window behind the cursor that has no partition: history not yet moved, or a row written with a key no partition covers. No maintenance run reaches them, retention included. | Run `backfill` (`partition_data`). |
0 commit comments