Andres Freund <andres@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