I've rearranged the sequence of some lines in the previous post to
facilitate discussion. I hope no offense is taken.
>>> "Robert Haas" wrote:
> On further review, I actually think that our documentation is pretty
> clear about this topic, too. Everything we've talked about thus far
> all s
On Fri, 2009-01-02 at 13:47 -0500, Tom Lane wrote:
> "Kevin Grittner" writes:
> >> What do you mean by referential integrity? I don't believe you can
> >> construct a foreign key problem at any transaction isolation level.
>
> > I mean that if someone attempts to maintain referential integrity
> I mean that if someone attempts to maintain referential integrity with
> SQL code, without using explicit locks, it is not reliable.
> Presumably the implementation of foreign keys in PostgreSQL takes this
> into account and blocks the kind of behavior shown below. This
> behavior would not occu
"Kevin Grittner" writes:
>> What do you mean by referential integrity? I don't believe you can
>> construct a foreign key problem at any transaction isolation level.
> I mean that if someone attempts to maintain referential integrity with
> SQL code, without using explicit locks, it is not reli
>>> "Robert Haas" wrote:
>> Not sure about "most". Referential integrity is a pretty common
use
>> case, and it is not covered without explicit locking. Many other
>> common use cases are not, either. I agree many are, and that the
rest
>> can be worked around easily enough that I wouldn't wa
> Not sure about "most". Referential integrity is a pretty common use
> case, and it is not covered without explicit locking. Many other
> common use cases are not, either. I agree many are, and that the rest
> can be worked around easily enough that I wouldn't want to see
> blocking introduced
>>> Simon Riggs wrote:
> On Mon, 2008-12-29 at 18:13 -0600, Kevin Grittner wrote:
>
>> I hope someone can show me something good I've missed so far.
>
> You're viewing this in problem-exposed language, unintentionally I'm
> sure.
Hmmm My meaning was, "I hope someone can point me to a goo
On Mon, 2008-12-29 at 18:13 -0600, Kevin Grittner wrote:
> I hope someone can show me something good I've missed so far.
You're viewing this in problem-exposed language, unintentionally I'm
sure. My viewpoint on this is that database concurrency is a big issue,
but that the way we do things roun
>>> "Robert Haas" wrote:
>> The effects are different, I think, in that there isn't a
>> serialization failure in some conflict cases where you would get
one
>> with actual updates. I found a paper on how to use updates to
provide
>> serializable transactions in a snapshot database, and I'd hav
> The effects are different, I think, in that there isn't a
> serialization failure in some conflict cases where you would get one
> with actual updates. I found a paper on how to use updates to provide
> serializable transactions in a snapshot database, and I'd have to
> review closely to see how
>>> "Robert Haas" wrote:
> On Mon, Dec 29, 2008 at 9:28 PM, Gregory Stark
wrote:
>> "Kevin Grittner" writes:
>>> (3) A finer-grained approach would be to make no-effect updates
to
>>> rows to lock them if they are to be read for purposes of updating
>>> something else in the transaction. This
On Mon, Dec 29, 2008 at 9:28 PM, Gregory Stark wrote:
> "Kevin Grittner" writes:
>> (3) A finer-grained approach would be to make no-effect updates to
>> rows to lock them if they are to be read for purposes of updating
>> something else in the transaction. This could have a high cost in
>> dis
"Kevin Grittner" writes:
> (3) A finer-grained approach would be to make no-effect updates to
> rows to lock them if they are to be read for purposes of updating
> something else in the transaction. This could have a high cost in
> disk access and table bloat. It has the advantage of providing
13 matches
Mail list logo
