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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
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 previou
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 exceptio
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
>> w
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
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
> > Postg
On Wed, Dec 14, 2016 at 8:38 AM, Robert Haas wrote:
> On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote:
>> Predicate locks
>> from reads within subtransactions are not discarded, even if the
>> work of the subtransaction is otherwise discarded.
>
> Oh, interesting. Just to be clear, I'm no
On Wed, Dec 14, 2016 at 9:40 AM, Kevin Grittner wrote:
> On Wed, Dec 14, 2016 at 8:27 AM, Robert Haas wrote:
>> But even after that fix, at the least, you'll still be able to
>> demonstrate the same problem by trapping serialization_failure rather
>> than unique_constraint.
>
> I hope not; the "d
On Wed, Dec 14, 2016 at 8:27 AM, Robert Haas wrote:
> But even after that fix, at the least, you'll still be able to
> demonstrate the same problem by trapping serialization_failure rather
> than unique_constraint.
I hope not; the "doomed" flag associated with a serializable
transaction should c
Thanks for the reply.
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 of (2) above. As far as I
> can see, that would require using S2PL -- something the community
> ripped out
On Wed, Dec 14, 2016 at 12:44 AM, Robert Haas wrote:
> On Tue, Dec 13, 2016 at 1:00 PM, Ian Jackson
> wrote:
> Saying that a set of transactions are serializable is equivalent to
> the statement that there is some serial order of execution which would
> have produced results equivalent to the a
On Wed, Dec 14, 2016 at 9:05 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> I have not read any database literature on the interaction of
>> serializability with subtransactions. This seems very thorny.
>> Suppose T1 reads A and B and updates A -> A' while concurrently T2
>> reads A and B and
Robert Haas wrote:
> I have not read any database literature on the interaction of
> serializability with subtransactions. This seems very thorny.
> Suppose T1 reads A and B and updates A -> A' while concurrently T2
> reads A and B and updates B -> B'. This is obviously not
> serializable; if ei
On Tue, Dec 13, 2016 at 1:00 PM, Ian Jackson wrote:
> The conversion is as follows: if a scenario is affected by the caveat,
> in there must be at least one transaction T which firstly produces
> "impossible" results I, and in which some later statement S produces a
> serialisation failure.
>
> To
On Tue, Dec 13, 2016 at 12:00 PM, Ian Jackson wrote:
> Kevin Grittner writes:
> I still hope to be able to convince you that the definition of
> SERIALIZABLE (in the pgsql docs) ought to be a stronger version, which
> covers even non-committed transactions.
That doesn't seem likely. The stronge
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages]"):
> [various things]
I get the feeling from your message that I have irritated you. I'm
sorry if I have. In particular, I wanted to say that I cert
On Tue, Dec 13, 2016 at 9:50 AM, Ian Jackson wrote:
> Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db:
> Retry on constraint violation [and 2 more messages]"):
>> On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson
>> wrote:
>>> Are all o
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages]"):
> On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson
> wrote:
> > Are all of these cases fixed by fcff8a57519847 "Detect SSI conflicts
>
On Tue, Dec 13, 2016 at 5:30 AM, Ian Jackson wrote:
> I am concerned that there are other possible bugs of this form.
> In earlier messages on this topic, it has been suggested that the
> "impossible" unique constraint violation is only one example of a
> possible "leakage".
As I see it, the mai
Thanks to everyone for your attention.
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation"):
> On Mon, Dec 12, 2016 at 8:45 AM, Ian Jackson
> wrote:
> > AIUI the documented behavour is that "every set of successful
> > transactions is seriali
27 matches
Mail list logo