Florian Pflug wrote:
> Yeah MS-SQL really isn't the idea target for comparison here. You
> can override pretty much any lock that MS-SQL takes with a
> stronger or weaker one from what I've seen. I wouldn't be at all
> surprised if you could convince it to work either way by putting
> some (prob
On Jul 11, 2011, at 11:55 AM, "Kevin Grittner"
wrote:
> Robert Haas wrote:
>
>> I find these responses to be a bit off point.
>
> The OP is basically looking for what Florian tried to implement.
> This is perhaps a *bit* off point, but arguably not more than
> pointing someone who is requesti
Heikki Linnakangas wrote:
> On 11.07.2011 18:44, Kevin Grittner wrote:
>> (In our in-house testing I've so far found one place where we
>> needed to take an explicit lock on a dummy table we created just
>> to control access to a sequence -- sequences don't follow normal
>> transactional semantics
On Jul11, 2011, at 20:16 , Kevin Grittner wrote:
> Florian Pflug wrote:
>> Part (B) has some relationship to what I tried to archive by
>> changing the way REPEATABLE READ transactions and row locks
>> interact. Though my intention wasn't full serializability, only
>> enough protection to make use
Florian Pflug wrote:
> Part (B) has some relationship to what I tried to archive by
> changing the way REPEATABLE READ transactions and row locks
> interact. Though my intention wasn't full serializability, only
> enough protection to make user-space FOREIGN KEYS work safely for
> REPEATABLE READ
On Jul11, 2011, at 18:55 , Kevin Grittner wrote:
> Robert Haas wrote:
>> I find these responses to be a bit off point.
>
> The OP is basically looking for what Florian tried to implement.
> This is perhaps a *bit* off point, but arguably not more than
> pointing someone who is requesting planner
"Kevin Grittner" wrote:
> I'm wondering if it wouldn't make sense to dodge all that by
> having SELECT FOR UPDATE simple *do* a no-op UPDATE RETURNING.
Hmm.
Patrick, would it be possible to change the PostgreSQL code for
Hibernate to use UPDATE RETURNING instead of SELECT FOR UPDATE?
That m
Robert Haas wrote:
> I find these responses to be a bit off point.
The OP is basically looking for what Florian tried to implement.
This is perhaps a *bit* off point, but arguably not more than
pointing someone who is requesting planner hints in another
direction. And someone thought the iss
Robert Haas writes:
> I find these responses to be a bit off point. Not everyone can or will
> want to use SERIALIZABLE. The OP's point is that we - particularly
> Tom - have argued in the past that we shouldn't allow this because
> it's too ill-defined and/or confusing. Evidently our competition
On Jul 11, 2011, at 10:44 AM, "Kevin Grittner"
wrote:
> Heikki Linnakangas wrote:
>> On 11.07.2011 05:45, Patrick Earl wrote:
>>> The ability to lock on outer joins is quite useful. I've even
>>> been contacted to ask if I was aware of any progress in this
>>> area.
>>
>> 9.1 has a truly seria
On 11.07.2011 18:44, Kevin Grittner wrote:
(In our in-house
testing I've so far found one place where we needed to take an
explicit lock on a dummy table we created just to control access to
a sequence -- sequences don't follow normal transactional
semantics.)
Hmm, is that something we should d
Heikki Linnakangas wrote:
> On 11.07.2011 05:45, Patrick Earl wrote:
>> The ability to lock on outer joins is quite useful. I've even
>> been contacted to ask if I was aware of any progress in this
>> area.
>
> 9.1 has a truly serializable isolation level, so I would suggest
> using that instead
On 11.07.2011 05:45, Patrick Earl wrote:
The ability to lock on outer joins is quite useful. I've even been
contacted to ask if I was aware of any progress in this area.
9.1 has a truly serializable isolation level, so I would suggest using
that instead of SELECT FOR UPDATE.
--
Heikki Lin
Okay, I finally had time to install a bunch of databases and see what
the "industry" thinks.
I tested the four seemingly most pertinent databases. The ability to
"select for update" with a left outer join is present on these
databases:
* Oracle
* SQL Server (not the same syntax, but does support
On May 1, 2011, at 12:27 PM, Patrick Earl wrote:
> In ORMs like NHibernate, there are a few strategies for mapping
> inheritance to SQL. One of these is "Joined Subclass," which allows
> for the elimination of duplicate data and clean separation of class
> contents.
>
> With a class hierarchy suc
Patrick Earl writes:
> On Sun, May 1, 2011 at 9:00 PM, Tom Lane wrote:
>> Addition of new rows certainly isn't supposed to be prevented by a
>> SELECT FOR UPDATE, but that's not the problem here. What I *do* expect
>> a SELECT FOR UPDATE to promise is that the rows it did return can't
>> change
On Sun, May 1, 2011 at 9:00 PM, Tom Lane wrote:
> Addition of new rows certainly isn't supposed to be prevented by a
> SELECT FOR UPDATE, but that's not the problem here. What I *do* expect
> a SELECT FOR UPDATE to promise is that the rows it did return can't
> change or be deleted by someone els
Patrick Earl writes:
> On Sun, May 1, 2011 at 4:05 PM, Tom Lane wrote:
>> Quite. What would it mean to lock the absence of a row?
> I would argue that SELECT FOR UPDATE never locks on the absence of a
> row. For example, if I do:
> SELECT * FROM Table WHERE Column = 10
> The existing rows ar
On Sun, May 1, 2011 at 4:05 PM, Tom Lane wrote:
> Patrick Earl writes:
>> The query to get all the pets is as follows:
>
>> select * from Pet
>> left join Dog on Dog.Id = Pet.Id
>> left join Cat on Cat.Id = Pet.Id
>
>> Now suppose you want to lock to ensure that your Cat is not updated
>> concurr
Patrick Earl writes:
> The query to get all the pets is as follows:
> select * from Pet
> left join Dog on Dog.Id = Pet.Id
> left join Cat on Cat.Id = Pet.Id
> Now suppose you want to lock to ensure that your Cat is not updated
> concurrently. You add FOR UPDATE, but then PostgreSQL gets upset
[I previously posted this to pgsql-sql, but received no response as of
yet... it's more of a development team oriented message in any case.]
In ORMs like NHibernate, there are a few strategies for mapping
inheritance to SQL. One of these is "Joined Subclass," which allows
for the elimination of d
21 matches
Mail list logo
