forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit6f2aead
committed
In XLogReadBufferExtended, don't assume P_NEW yields consecutive pages.
In a database that's not yet reached consistency, it's possible that somesegments of a relation are not full-size but are not the last ones either.Because of the way smgrnblocks() works, asking for a new page with P_NEWwill fill in the last not-full-size segment --- and if that makes it fullsize, the apparent EOF of the relation will increase by more than one page,so that the next P_NEW request will yield a page past the next consecutiveone. This breaks the relation-extension logic in XLogReadBufferExtended,possibly allowing a page update to be applied to some page far past whereit was intended to go. This appears to be the explanation for reports oftable bloat on replication slaves compared to their masters, and probablyexplains some corrupted-slave reports as well.Fix the loop to check the page number it actually got, rather than merelyAssert()'ing that dead reckoning got it to the desired place. AFAICT,there are no other places that make assumptions about exactly which pagethey'll get from P_NEW.Problem identified by Greg Stark, though this is not the same as hisproposed patch.It's been like this for a long time, so back-patch to all supportedbranches.1 parent48870dd commit6f2aead
1 file changed
+9
-3
lines changedLines changed: 9 additions & 3 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
338 | 338 |
| |
339 | 339 |
| |
340 | 340 |
| |
341 |
| - | |
| 341 | + | |
342 | 342 |
| |
343 | 343 |
| |
344 | 344 |
| |
345 | 345 |
| |
346 | 346 |
| |
347 |
| - | |
348 | 347 |
| |
349 |
| - | |
| 348 | + | |
| 349 | + | |
| 350 | + | |
| 351 | + | |
| 352 | + | |
| 353 | + | |
| 354 | + | |
| 355 | + | |
350 | 356 |
| |
351 | 357 |
| |
352 | 358 |
| |
|
0 commit comments
Comments
(0)