{"action":"opened","issue":{"url":"https://api.github.com/repos/codership/mysql-wsrep/issues/339","repository_url":"https://api.github.com/repos/codership/mysql-wsrep","labels_url":"https://api.github.com/repos/codership/mysql-wsrep/issues/339/labels{/name}","comments_url":"https://api.github.com/repos/codership/mysql-wsrep/issues/339/comments","events_url":"https://api.github.com/repos/codership/mysql-wsrep/issues/339/events","html_url":"https://github.com/codership/mysql-wsrep/issues/339","id":354918038,"node_id":"MDU6SXNzdWUzNTQ5MTgwMzg=","number":339,"title":"Documentation ambiguity about wsrep_sync_wait","user":{"login":"GeoffMontee","id":2981647,"node_id":"MDQ6VXNlcjI5ODE2NDc=","avatar_url":"https://avatars2.githubusercontent.com/u/2981647?v=4","gravatar_id":"","url":"https://api.github.com/users/GeoffMontee","html_url":"https://github.com/GeoffMontee","followers_url":"https://api.github.com/users/GeoffMontee/followers","following_url":"https://api.github.com/users/GeoffMontee/following{/other_user}","gists_url":"https://api.github.com/users/GeoffMontee/gists{/gist_id}","starred_url":"https://api.github.com/users/GeoffMontee/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GeoffMontee/subscriptions","organizations_url":"https://api.github.com/users/GeoffMontee/orgs","repos_url":"https://api.github.com/users/GeoffMontee/repos","events_url":"https://api.github.com/users/GeoffMontee/events{/privacy}","received_events_url":"https://api.github.com/users/GeoffMontee/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-08-28T21:52:44Z","updated_at":"2018-08-28T21:52:44Z","closed_at":null,"author_association":"NONE","body":"The [documentation](http://galeracluster.com/documentation-webpages/mysqlwsrepoptions.html?highlight=wsrep_sync_wait#wsrep-sync-wait) says the following about wsrep_sync_wait:\r\n\r\n> For example, say that you have a web application. At one point in its run, you need it to perform critical read. That is, you want the application to access the database server and run a SELECT query that must return the most up to date information possible.\r\n> \r\n> SET SESSION wsrep_sync_wait=1;\r\n> SELECT * FROM example WHERE field = \"value\";\r\n> SET SESSION wsrep_sync_wait=0\r\n> \r\n> In the example, the application first runs a SET command to enable wsrep_sync_wait for READ statements, then it makes a SELECT query. Rather than running the query, the node initiates a causality check, **blocking incoming queries while it catches up with the cluster**. When the node finishes applying the new transaction, it executes the SELECT query and returns the results to the application. The application, having finished the critical read, disables wsrep_sync_wait, returning the node to normal operation.\r\n\r\nWhen the documentation says that galera **blocks incoming queries while it catches up with the cluster** while a session initiates a causality check, I believe this means that new queries are blocked in only the session that is performing the causality check. However, the statement is somewhat ambiguous, so some people might think that this means that **all** queries will be blocked on the node during this time. This section should probably be clarified, so that it is less ambiguous."}}
{"actor":{"display_login":"GeoffMontee"}}