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