"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Ok, you answered my next question. Part of my confusion here is the
> comments in front of LockAcquire() which explains how userlocks are
> supposed to be mapped to the lock tag. In the case of userlocks, the
> locktag is basically a hash key, right?
Those are just comments ;-). You have a hash tag and you can do
anything you like with it ... except make it bigger ... the lockmethod
field is sufficient to keep it from colliding with any system-generated
tags.
> ctid is useless for user locks because an update from a non-cooperating
> client will change it unless the locks become non-cooperative,
[ shrug... ] Since userlocks are only advisory, a non-cooperating
client can break anything in sight anyway. I don't find the above
argument convincing. But in any case, you can use an OID or serial
sequence identifier if you prefer that to CTID. They're just integers
and it's really up to the user application to define the interpretation
of a userlock tag.
> IOW, a 'user lock' candidate identifier generated by the database
> must be both unique and persistent for the lifetime of the lock.
See above. The database isn't defining anything here.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
