Re: Question about SSI, subxacts, and aborted read-only xacts - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Question about SSI, subxacts, and aborted read-only xacts
Date
Msg-id 5055FB56020000250004A442@gw.wicourts.gov
Whole thread Raw
In response to Question about SSI, subxacts, and aborted read-only xacts  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Question about SSI, subxacts, and aborted read-only xacts  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Question about SSI, subxacts, and aborted read-only xacts  (Jeff Davis <pgsql@j-davis.com>)
Re: Question about SSI, subxacts, and aborted read-only xacts  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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



Attachment

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: [WIP] Patch : Change pg_ident.conf parsing to be the same as pg_hba.conf
Next
From: Tom Lane
Date:
Subject: Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed