Andres Freund <and...@anarazel.de> wrote: > On Wednesday 21 Sep 2011 19:24:55 Tom Lane wrote: >> One question is what you think the lock means. I believe for >> example that taking a non-exclusive regular table lock on a >> sequence would not prevent other sessions from doing nextval(); >> even an exclusive one would not prevent them from doing so if >> they had pre-cached values. > I don't see what a non-exclusive lock on a sequence should > sensibly do so I don't see a problem with not supporting them. > That already cached values are not affected by the lock seems to > be pretty logical to me - and not really problematic. > At least in my cases I would look at last_value from the sequence > after locking it- which includes the cached values so its fine > that they can be used. > The case that somebody already acquired a sequence value that not > visible to other sessions has to be taken into account anyway. I think all of that holds for us, as well. Our only real use for this (so far, anyway) is in our trigger-based replication -- a deferred AFTER INSERT trigger assigns a strictly monotonically increasing commit number which must match the order of commit. I don't see how getting an exclusive lock on the sequence itself could introduce any bugs which we wouldn't have using a dummy table created only to serve as a lock target. Given that I can't think of any other uses for this feature, I guess it would be pretty low on my list of priorities. As I said earlier, "it would be nice." -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
