mirror of
https://github.com/neondatabase/neon.git
synced 2026-01-09 22:42:57 +00:00
bfb20522eb
The GetPage@LSN requests used last flushed WAL position as the request LSN, but the last flushed WAL position might point in the middle of a WAL record (most likely at a page boundary). But we used to only update the "last valid LSN" after fully decoding a record. As a result, this could happen: 1. Postgres generates two WAL record. They span from 0/10000 to 0/20000, and from 0/20000 to 0/30000. 2. Postgres flushes the WAL to 0/25000. 3. Page server receives the WAL up to 0/25000. It decodes the first WAL record and advances the last valid LSN to the end of that record, 0/20000 3. Postgres issues a GetPage@LSN request, using 0/15000 as the request LSN. 4. The GetPage@LSN request is stuck in the page server, because last valid LSN is 0/10000, and the request LSN is 0/15000. This situation gets unwedged when something kicks a new WAL flush in the Postgres server, like a new transaction. But that can take a long time. Fix by updating the last valid LSN to the last received LSN, even if it points in the middle of a record.
Zenith
Zenith substitutes PostgreSQL storage layer and redistributes data across a cluster of nodes
Running tests
git clone --recursive https://github.com/libzenith/zenith.git
./pgbuild.sh # builds postgres and installs it to ./tmp_install
cargo test