-
Notifications
You must be signed in to change notification settings - Fork 22
Use correct LSN in GetPage@LSN calls when nothing has been evicted yet. #40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@lubennikovaav, can you take a look at this please? I didn't understand the changes in commit 153dee9 |
lubennikovaav
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
commit 153dee9 was introduced to fix a race when we were requesting a page before walreceiver started. To avoid eternal waiting, we simply request page with a special (invalid) LSN and pageserver just returns the latest version of the page.
see https://github.com/zenithdb/zenith/blob/main/pageserver/src/page_cache.rs#L873
Looks like this is not needed anymore, since we decided to handle shared relations and non-rels locally after initial setup.
|
|
||
| /* The record should've been flushed already, since it was evicted, but let's be safe */ | ||
| if (lsn > flushlsn) | ||
| XLogFlush(lsn); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My first thought was how is it even legal, let's use Assert instead.
But it seems to be a normal situation. Let's explain it in the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. Is it legal? I can't think of a legit scenario either
If no page has been evicted from page cache yet, use the latest flushed LSN. Commit 153dee9, "Request special lsn during bootstrap", changed this but it is not clear to me why. As far as I can see, this isn't related to bootstrapping, and using the latest flushed LSN should always work. While we're at it, rearrange the code slightly for readability, and add comments.
7ac02d9 to
65b907b
Compare
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
primary_conninfo string is too long with password. Wal receiver reads the password from NEON_AUTH_TOKEN instead.
If no page has been evicted from page cache yet, use the latest flushed
LSN.
Commit 153dee9, "Request special lsn during bootstrap", changed this
but it is not clear to me why. As far as I can see, this isn't related
to bootstrapping, and using the latest flushed LSN should always work.
While we're at it, rearrange the code slightly for readability, and add
comments.