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
I'm still casting about to make sure I have my head around the issues
adequately to suggest a documentation update. Here's my current
understanding.
The below is intended to help define the nature and scope of the
issue, not be the sort of text that belongs in user documentation.
Assume transa
14 matches
Mail list logo
