On Sun, Sep 17, 2006 at 07:38:38PM -0400, Tom Lane wrote: > * The contrib/userlock replacement issue > > We have three possible choices for this: do nothing, install a > bug-compatible, allegedly-clean-room implementation in contrib: > http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.php > or put a hopefully-cleaner design into core, eg per my suggestions here: > http://archives.postgresql.org/pgsql-hackers/2006-09/msg00467.php > I favor the third alternative, mainly because by changing the API > we remove all doubt as to whether any "intellectual property" > remains from the original GPL'd code. However, we've got to make up > our minds and get on with it. One problem I see with userlock is that you're asking for lock ID conflicts unless you control everything on the system that's using userlocks. Right now, doing so probably isn't that difficult, but my hope is that as PostgreSQL becomes more acceptable we'll see more software written to use it... software that might need to play well with other software within the same database.
I think the best way to fix this is to set aside some range of the lock ID space for a naming scheme that is based on schemas, or some other kind of text identifier. I think this really just amounts to putting some recommended practices into the docs; perhaps not using any int4,int4 IDs where the first int is larger than 16k or whatever the maximum system OID is. That would allow for segmenting locks based on schema OIDs. Down the road we might want a nicer, schema-based interface, but just setting aside the space should be fine for now. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
