On Mon, Feb 29, 2016 at 9:05 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > > Hi Thomas, > > On 2016/02/29 15:20, Thomas Munro wrote: >> Thanks for looking at the patch! Here is a new version with the >> following changes: >> >> 1. Some draft user documentation has been added, as requested. > > Just to clarify, in: > > + servers. A transaction that is run with > <varname>causal_reads</> set > + to <literal>on</> is guaranteed either to see the effects of all > + completed transactions run on the primary with the setting on, or to > + receive an error "standby is not available for causal reads". > > "A transaction that is run" means "A transaction that is run on a > standby", right?
Well, it could be any server, standby or primary. Of course standbys are the interesting case since it it was already true that if you run two sequential transactions run on the primary, the second can see the effect of the first, but I like the idea of a general rule that applies anywhere, allowing you not to care which server it is. > By the way, is there some discussion in our existing > documentation to refer to about causal consistency in single node case? I > don't know maybe that will help ease into the new feature. Grepping the > existing source tree doesn't reveal the term "causal", so maybe even a > single line in the patch mentioning "single node operation trivially > implies (or does it?) causal consistency" would help. Thoughts? Hmm. Where should such a thing go? I probably haven't introduced the term well enough. I thought for a moment about putting something here: http://www.postgresql.org/docs/devel/static/sql-commit.html "All changes made by the transaction become visible to others ..." -- which others? But I backed out, that succinct account of COMMIT is 20 years old, and in any case visibility is tied to committing, not specifically to the COMMIT command. But perhaps this patch really should include something there that refers back to the causal reads section. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers