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 jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
