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
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
Alvaro Herrera 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
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 (wi
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
On Mon, Sep 10, 2012 at 10:44:57PM -0700, Jeff Davis wrote:
> For the archives, and for those not following the paper in detail, there
> is one situation in which SSI will abort a read-only transaction.
>
> When there are three transactions forming a dangerous pattern where T1
> (read-only) has a
On Mon, 2012-09-10 at 11:15 -0500, Kevin Grittner wrote:
> That's a fair point. Do you have any suggested wording, or
> suggestions for exactly where in the documentation you think it
> would be most helpful? The subsection on serializable transactions
> seems like the most obvious location:
Att
On Mon, 2012-09-10 at 21:59 -0400, Dan Ports wrote:
> It might be worth noting that serializable mode will not cause
> read-only transactions to fail to commit
For the archives, and for those not following the paper in detail, there
is one situation in which SSI will abort a read-only transaction.
On Sat, Sep 08, 2012 at 11:34:56AM -0700, Jeff Davis wrote:
> If so, I think we need a documentation update. The serializable
> isolation level docs don't quite make it clear that serializability only
> applies to transactions that commit. It might not be obvious to a user
> that there's a differen
Jeff Davis wrote:
> Oh, I see the distinction you're making: in PL/pgSQL, the
> exception mechanism involves *implicit* subtransaction rollbacks.
> That's more of a language issue, but a valid point.
I think it holds for the general case of functions -- there's no
reason to believe that you ar
On Mon, 2012-09-10 at 11:15 -0500, Kevin Grittner wrote:
> ... and I know Jeff read that quite closely because he raised a
> question off-list about an error he found in it which managed to
> survive the many editing and review passes that paper went through.
> :-)
Well, I need to keep up with th
Jeff Davis wrote:
> This question comes about after reading the VLDB paper
> "Serializable Snapshot Isolation in PostgreSQL".
... and I know Jeff read that quite closely because he raised a
question off-list about an error he found in it which managed to
survive the many editing and review passe
This question comes about after reading the VLDB paper "Serializable
Snapshot Isolation in PostgreSQL".
We release predicate locks after a transaction abort, but not after a
subtransaction abort. The paper says that the reason is:
"We do not drop SIREAD locks acquired during a subtransaction if t
13 matches
Mail list logo
