I wrote:
> [for a description of traditional techniques for providing various
> isolation levels, including serializable], Dr. Cahill seemed to
> like (Hellerstein et al., 2007)
If anyone else is interested in this paper, here is additional
information:
Architecture of a Database System. (Jos
Florian Weimer wrote:
> * Florian Pflug:
>> On 16.12.09 16:40 , Kevin Grittner wrote:
>>> Nicolas Barbier wrote:
>>>
I am not sure whether the serialization failures that it may
cause are dependent on the plan used.
>>>
>>> They are.
>>
>> But so are failures due to deadlocks even today
On 18.12.09 17:33 , Nicolas Barbier wrote:
I would guess that currently, whether deadlocks can be triggered by
a set of transactions (i.e., sequences of SQL statements) depends on
the plan only marginally*. E.g., if two plans happen to use the same
index, rows may always get locked in the same or
On 18.12.09 16:42 , Florian Weimer wrote:
* Florian Pflug:
On 16.12.09 16:40 , Kevin Grittner wrote:
Nicolas Barbier wrote:
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
They are.
But so are failures due to deadlocks even today, no?
2009/12/18 Florian Weimer :
> * Florian Pflug:
>
>> On 16.12.09 16:40 , Kevin Grittner wrote:
>>
>>> Nicolas Barbier wrote:
>>>
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
>>>
>>> They are.
>>
>> But so are failures due to deadlock
* Florian Pflug:
> On 16.12.09 16:40 , Kevin Grittner wrote:
>> Nicolas Barbier wrote:
>>
>>> I am not sure whether the serialization failures that it may cause
>>> are dependent on the plan used.
>>
>> They are.
>
> But so are failures due to deadlocks even today, no?
They are detected. In th
Nicolas Barbier wrote:
> Therefore, with next-key locking you better don't have too many table
> scans if you want to have any concurrent transactions.
Well, I would say that you don't want too many table scans on heavily
updated tables if you don't want too many serialization failures. Keep
in
"Albe Laurenz" wrote:
> I would say that in the case of a table scan, the whole table will
> be SILOCKed. I guess that's pretty much unavoidable if you want
> serializability.
Agreed.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On 16.12.09 16:40 , Kevin Grittner wrote:
Nicolas Barbier wrote:
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
They are.
But so are failures due to deadlocks even today, no? The processing
order of UPDATES which involve joins isn't any
[ Forgot the list, resending. ]
2009/12/16 Boszormenyi Zoltan :
> Robert Haas írta:
>
>> On Wed, Dec 16, 2009 at 1:25 PM, Robert Haas wrote:
>>
>>> On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera
>>> wrote:
>>>
So you'd have to disable HOT updates when true serializability was
active?
Robert Haas wrote:
> > A predicate can include columns from an index plus others.
> > Am I missing something?
>
> Hmm, interesting point. In that case you couldn't use the index to
> enforce predicate locking under MVCC without disabling HOT. But there
> will be other cases where that wouldn't h
Robert, Please forgive a couple editorial inserts to your statement
-- I hope it clarifies. If I've distorted your meaning, feel free
to straighten me out. :-)
Robert Haas wrote:
> This thread veered off into a discussion of the traditional
> [predicate locking] technique, rather than the [
On Wed, Dec 16, 2009 at 1:30 PM, Kevin Grittner
wrote:
> Alvaro Herrera wrote:
>
>> So you'd have to disable HOT updates when true serializability was
>> active?
>
> I wouldn't think so; but someone familiar with HOT logic could
> probably determine whether the unmodified algorithm could be used
On Wed, Dec 16, 2009 at 1:29 PM, Boszormenyi Zoltan wrote:
> Robert Haas írta:
>> On Wed, Dec 16, 2009 at 1:25 PM, Robert Haas wrote:
>>
>>> On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera
>>> wrote:
>>>
Robert Haas escribió:
> On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund
Alvaro Herrera wrote:
> So you'd have to disable HOT updates when true serializability was
> active?
I wouldn't think so; but someone familiar with HOT logic could
probably determine whether the unmodified algorithm could be used by
reviewing the "simplifying assumptions" near the bottom of pa
Robert Haas írta:
> On Wed, Dec 16, 2009 at 1:25 PM, Robert Haas wrote:
>
>> On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera
>> wrote:
>>
>>> Robert Haas escribió:
>>>
On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote:
> On Wednesday 16 December 2009 16:
On Wed, Dec 16, 2009 at 1:25 PM, Robert Haas wrote:
> On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera
> wrote:
>> Robert Haas escribió:
>>> On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote:
>>> > On Wednesday 16 December 2009 16:24:42 Robert Haas wrote:
>>> >> > Inserts and deletes follow
On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote:
>> > On Wednesday 16 December 2009 16:24:42 Robert Haas wrote:
>> >> > Inserts and deletes follow the same protocol, obtaining an exclusive
>> >> > lock on
Robert Haas escribió:
> On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote:
> > On Wednesday 16 December 2009 16:24:42 Robert Haas wrote:
> >> > Inserts and deletes follow the same protocol, obtaining an exclusive
> >> > lock on the row after the one being inserted or deleted. The result
>
Nicolas Barbier wrote:
> I am not sure whether the serialization failures that it may cause
> are dependent on the plan used.
They are.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
"Albe Laurenz" wrote:
> Although it may have seemed that I was out to shoot the idea down,
> I am interested in the topic. I guess my way of understanding
> something is trying to find holes in it...
No problem. That's how ideas are explored and improved. The brick
wall was that there seemed
On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote:
> On Wednesday 16 December 2009 16:24:42 Robert Haas wrote:
>> > Inserts and deletes follow the same protocol, obtaining an exclusive
>> > lock on the row after the one being inserted or deleted. The result
>> > of this locking protocol
Moin,
On Wednesday 16 December 2009 16:24:42 Robert Haas wrote:
> > Inserts and deletes follow the same protocol, obtaining an exclusive
> > lock on the row after the one being inserted or deleted. The result
> > of this locking protocol is that a range scan prevents concurrent
> > inserts
On Wed, Dec 16, 2009 at 4:52 AM, Albe Laurenz wrote:
> Kevin Grittner wrote:
>> Just to make those who care aware of it, here is Michael Cahill's
>> Doctoral Thesis based on implementing Serializable Snapshot
>> Isolation in InnoDB using a refined version of the techniques
>> previously used in th
Nicolas Barbier wrote:
>> Quote:
[...]
>>
>> That sounds like it should actually work.
>
> That boils down to 2PL, using a granularity that is somewhere between
> table locks and single-row locks (note that the latter doesn't
> correctly enforce serializability, hence something more coarse which
>
* Albe Laurenz:
> That sounds like it should actually work.
If you have got an index, yes. It seems to me that it would make
locking behavior dependent on your query plan, too.
BTW, PostgreSQL could raise a different error when a unique constraint
violation is detected which involves a row whic
2009/12/16 Albe Laurenz :
> Quote:
> The problem [of phantom reads] was identified in (Eswaran et al., 1976),
> but the general purpose "predicate locking" solution suggested there
> has not been widely adopted because of the difficulty in testing mutual
> satisfiability of predicates.
>
>
Kevin Grittner wrote:
> Just to make those who care aware of it, here is Michael Cahill's
> Doctoral Thesis based on implementing Serializable Snapshot
> Isolation in InnoDB using a refined version of the techniques
> previously used in the Berkley DB (and previously discussed on this
> list):
>
Just to make those who care aware of it, here is Michael Cahill's
Doctoral Thesis based on implementing Serializable Snapshot
Isolation in InnoDB using a refined version of the techniques
previously used in the Berkley DB (and previously discussed on this
list):
http://hdl.handle.net/2123/5353
29 matches
Mail list logo
