Re: Select For Update and Left Outer Join
От | Kevin Grittner |
---|---|
Тема | Re: Select For Update and Left Outer Join |
Дата | |
Msg-id | 4E1AFF46020000250003F1D7@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Select For Update and Left Outer Join (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> 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.) > > Hmm, is that something we should do something about? Can you give > an example of that? Sequences behave in a non-transactional way for good reason; I certainly wouldn't advocate changing that. This came up in some fairly specialized code in our replication system. Existing PostgreSQL features were fine for dealing with it, although the ability to take out a lock on a sequence (just as one would on a table) would have been convenient (as it would have allowed us to avoid using a dummy table). The more important issue is probably around the docs making clear that the serializable transaction isolation level doesn't make certain things beyond DML serializable. > Not in 9.1, except in the docs if we don't mention that already, > but in the future... I thought it was mentioned in the docs, but in a scan through the Concurrency Control chapter I'm not seeing it. Basically, SSI is only going to work with objects and statements which are currently using MVCC snapshots for snapshot isolation; anything else behaves exactly as it did in 9.0 at the serializable isolation level. I'm not quite sure where this should be mentioned. Ideas? -Kevin
В списке pgsql-hackers по дате отправления: