-
Notifications
You must be signed in to change notification settings - Fork 90
Refactor code to fetch current LSN position from Postgres. #608
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
" write_lsn pg_lsn, flush_lsn pg_lsn, replay_lsn pg_lsn)" | ||
" write_lsn pg_lsn, flush_lsn pg_lsn, replay_lsn pg_lsn)", | ||
|
||
"create table lsn_tracking(source pg_lsn, target pg_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.
Are you planning to move file based lsn tracking to sqlite?
(I don't see this table being used anywhere.)
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.
Ooops, missed the clean-up for that. The idea crossed my mind yeah, but I wanted to clean-up some other aspects first (summary information and top-level timings in the SQLite database so that pgcopydb list summary
can represent multi-steps activity and also be used concurrently to the main command, or after the fact).
I also see lots of warnings after moving sentinel to sqlite. Should we change the log level to debug?
|
Either that or find a way to avoid the warning by having the data we're looking for? ;-) |
@dimitri What happens with my tests is that the source being ingested with parallel connections, but the target being replicated with single connection causing the huge lag between source & target. I'm wondering, why can't we just use the LSN from |
Ahh, I think we have to fetch LSN from target to compare against to find the durable LSN, not the source. Let me fix it. |
No description provided.