On 9/22/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
>> This is why I suggested we set aside some range of numbers that should
>> not be used. Doing so would allow adding a better-managed
>> numbering/naming scheme in the future.
> the whole point about advisory locks is that the provided lock space
> is unmanaged.
I think we forgot to document that the lock space is per-database; also,
ok. (ditto user lock legacy)
wouldn't it be a good idea to specifically recommend that advisory locks
be used only in databases that are used just by one application, or a
few cooperating applications? The lack of any permissions checks makes
them fairly unsafe in databases that are used by multiple users.
yes and no. so long as it is understood as lock space inside a single
database is shared by all sessions? what does it matter how many
applications are connecting? applications sharing a single database
implied that there is some negotiation of sharing of resources that
the server is not aware of. There is no specific objection to n
applictions using them on a shared database except for:
1. you must understand that the lock 'namespace' is at database level
2. memory for the lock table is sized for the database cluster, and is
shared with standard locks. use it up, and its game over.
imo, documentational thrust should be reinforcing those points and not
making any specific recommendations which are not derived from them.
I dont understand how having one or more applications has anything to
do with namespace conflicts, either you have a centrally managed way
of managing that namespace or you don't. the idea is just to make
sure you have one.
I would rather suggest, 'if you have multiple apps connection to the
same database, take care to...' etc. going the in the mvcc area which
deals (lightly) with locking strategies.
overall, the documentation is extremely light on strategies for
dealing with concurrency. however, something of a best practices might
be in order in light of these considerations.
I don't actually have a problem with the lack of security checks or
key range limitations --- I see advisory locks as comparable to large
objects, which are likewise permissions-free. It's an optional feature
and you just won't use it in databases where permission constraints are
a critical need. The thing that's bothering me is the relative ease of
accidental DoS to applications in *other* databases in the same cluster.
you have a point there.
merlin
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
