Re: Question about SSI, subxacts, and aborted read-only xacts

Jeff Davis wrote:
On Mon, 2012-09-10 at 11:15 -0500, Kevin Grittner wrote:

>> Do you have any suggested wording [...] ?

> Attached. I thought about putting it as a "note", but it seems like
> it's easy to go overboard with those.

I agree about a note being overkill for this.

I'm attaching an alternative proposal, with changes for the following
reasons:

(1) The complete re-wrap of that first paragraph made it really hard
to see what the actual change to the documentation was. I would
rather change it like this and have a separate patch to re-wrap the
paragraph (with no content change) or maybe restrict the reformatting
to two or three lines.

(2) The second paragraph starts with "There may still be
serialization anomalies involving aborted transactions" which seems
a bit alarming, seems to bend the definition of serialization
anomalies and seems odd to pick out for special attention when the
same could be said of data read in transactions at other isolation
levels if those transactions roll back from a deferred constraint or
a write conflict.

(3) There is a significant exception to this caveat which I felt
would be useful to people who wanted to generate big reports without
waiting for transaction commit: deferrable read-only transactions
offer applications a way to count on data as soon as it is read.

I'm not sure whether the omission of this from the docs should be
considered a big enough hazard to merit a back-patch, or if it should
just be committed to HEAD.

-Kevin

Excerpts from Kevin Grittner's message of dom sep 16 18:16:22 -0300 2012:

> (1) The complete re-wrap of that first paragraph made it really hard
> to see what the actual change to the documentation was. I would
> rather change it like this and have a separate patch to re-wrap the
> paragraph (with no content change) or maybe restrict the reformatting
> to two or three lines.

Have you tried git diff --color-words?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Excerpts from Kevin Grittner's message:
>
>> (1) The complete re-wrap of that first paragraph made it really
>> hard to see what the actual change to the documentation was. I
>> would rather change it like this and have a separate patch to
>> re-wrap the paragraph (with no content change) or maybe restrict
>> the reformatting to two or three lines.
>
> Have you tried git diff --color-words?

I had not noticed that option; thanks for pointing it out!

Given that there is an easy way for anyone to check the substance of
a change with this, I'm fine with what Jeff had for the first
paragraph.

-Kevin

On Sun, 2012-09-16 at 16:16 -0500, Kevin Grittner wrote:
> I'm attaching an alternative proposal, with changes for the following
> reasons:

Looks good to me, aside from not wrapping the text.

Regards,
Jeff Davis

On Sun, Sep 16, 2012 at 04:16:22PM -0500, Kevin Grittner wrote:
> I'm attaching an alternative proposal, with changes for the following
> reasons:
>
> (1) The complete re-wrap of that first paragraph made it really hard
> to see what the actual change to the documentation was. I would
> rather change it like this and have a separate patch to re-wrap the
> paragraph (with no content change) or maybe restrict the reformatting
> to two or three lines.
>
> (2) The second paragraph starts with "There may still be
> serialization anomalies involving aborted transactions" which seems
> a bit alarming, seems to bend the definition of serialization
> anomalies and seems odd to pick out for special attention when the
> same could be said of data read in transactions at other isolation
> levels if those transactions roll back from a deferred constraint or
> a write conflict.
>
> (3) There is a significant exception to this caveat which I felt
> would be useful to people who wanted to generate big reports without
> waiting for transaction commit: deferrable read-only transactions
> offer applications a way to count on data as soon as it is read.
>
> I'm not sure whether the omission of this from the docs should be
> considered a big enough hazard to merit a back-patch, or if it should
> just be committed to HEAD.

Patch applied to git head.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +