On Mon, Feb 29, 2016 at 9:05 PM, Amit Langote
<Langote_Amit_f8@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