I guess the preceding posts leave us with these guarantees about
read-only transactions which we might want to make explicit in the
documentation:
(1) A serialization failure cannot be initially thrown on a COMMIT
attempt for a read-only transaction; however, if a subtransaction
catches a seriali
On Fri, Dec 16, 2016 at 9:39 AM, Kevin Grittner wrote:
> Good catch!
Thanks!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Fri, Dec 16, 2016 at 8:24 AM, Robert Haas wrote:
> On Thu, Dec 15, 2016 at 9:01 AM, Kevin Grittner wrote:
>> I also realized some other properties of read-only transactions
>> that might interest you (and that I should probably document).
>> Since the only way for a read-only transaction to be
On Thu, Dec 15, 2016 at 9:01 AM, Kevin Grittner wrote:
> I also realized some other properties of read-only transactions
> that might interest you (and that I should probably document).
> Since the only way for a read-only transaction to be the on
> experiencing a serialization failure is if Tout
On Thu, Dec 15, 2016 at 9:53 AM, Ian Jackson wrote:
> I don't think "set max_pred_locks_per_transaction generously" is a
> practical thing to write in the documentation, because the application
> programmer, or admin, has no sensible way to calculate what a
> sufficiently generous value is.
ok
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson
> wrote:
> > [...] Are there other reasons,
> > besides previously suppressed serialisation failur
On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson wrote:
> However, in that example, as you seem to allude to, there is still a
> complete serialisation of all the transactions, even the failed T3:
> T1,T2,T3. The database has detected the problem before returning data
> in T3 that would contradict t
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> As Robert pointed out, a read-only transaction cannot normally be
> aborted by a serialization failure on COMMIT. Under exceptional
> conditions,
On Wed, Dec 14, 2016 at 11:12 AM, Ian Jackson wrote:
> Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db:
> Retry on constraint violation [and 2 more messages] [and 1 more messages]"):
>> On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson
>> wrote:
>> I would alter that slight
On Wed, Dec 14, 2016 at 11:20 AM, Ian Jackson wrote:
>> I'm not sure Ian is intentionally taking that position. Not all of us
>> are as familiar with the ramifications of every serializability
>> behavior we may want as you are.
>
> Indeed. I think it's fair to say that I'm totally unfamiliar wi
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson
> wrote:
>
> > Let me try to summarise my understanding of what the developers think
> > they can
On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson wrote:
> Let me try to summarise my understanding of what the developers think
> they can and intend to promise, about SERIALIZABLE transactions:
>
> There is a consistent serialisation of all transactions which
> successfully commit; or which do no
Robert Haas writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on
constraint violation [and 2 more messages]"):
> On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote:
> > considered. Essentially, the position Ian has been taking is that
> > PostgreSQL should provide the guarantee
13 matches
Mail list logo
