Skip to content
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

Database not immediately accessible #78

Closed
AshfordN opened this issue Feb 17, 2020 · 4 comments · Fixed by canonical/dqlite#395
Closed

Database not immediately accessible #78

AshfordN opened this issue Feb 17, 2020 · 4 comments · Fixed by canonical/dqlite#395
Labels
Bug Confirmed to be a bug

Comments

@AshfordN
Copy link

When using the driver sub-package, the database appears to be inaccessible before the execution of certain unrelated statements.
For example, in the demo, if you create an entry in the database using the update command, then restart the service and query that entry, using the query command, you are able to obtain the previously created value. However, if you remove the section of the query command code that creates the table if it does not already exist (here) and attempt the above scenario, you get an error saying that the table does not exist when you execute the query. The only way for the query to succeed is by first executing certain unrelated statements; such as the one that attempts to create the table, or something like: PRAGMA ignored_pragma

@freeekanayaka
Copy link
Contributor

Yeah, this is a bug. Basically it happens because the raft log has not been replayed. I'll try to fix it in the next days.

In the meantime, the workaround you figured will do (because "exec" statements cause the raft log to be fully replayed, while "query" statements don't).

AFAICT this issue should be specific only for the very first query, if no exec statement has been executed yet, all subsequent ones will behave as expected.

@freeekanayaka
Copy link
Contributor

It turns out that the proper fix in dqlite is slightly more involved than I thought. I'll need to do some code refactoring in order to do it cleanly.

In the meantime, PR #79 is a workaround that should avoid the problem at least if you use the Go client.

@freeekanayaka
Copy link
Contributor

The dqlite issue is tracked here canonical/dqlite#210.

@freeekanayaka
Copy link
Contributor

I just made a commit to revert PR #79 since it seems it's causing regressions, see https://github.com/lxc/lxd/issues/6913. We'll need to sort it out before re-enabling this workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Confirmed to be a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants