From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
Cc: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: userlock changes for 8.1/8.2 |
Date: | 2005-01-25 15:38:58 |
Message-ID: | 3558.1106667538@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> However, it would be nice to have system generated unique tuple
> identifier. There isn't one currently that would fit in the userlock
> restriction of 48 bits.
Sure there is: the ctid of a row in an agreed-on table works fine.
The reason it's system-wide unique is that user_locks.c forcibly
includes your database OID in the lock tag.
It would be reasonable to allow user control of the lock's relId field
and maybe even dbId field, but that just takes an expansion of the API
for user_locks.c. There's no need to put overhead on the rest of
Postgres for this.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | noman naeem | 2005-01-25 15:44:18 | how to add a new column in pg_proc table |
Previous Message | Magnus Hagander | 2005-01-25 14:42:54 | Re: psql 8.0 final not working on NT 4.0sp6 |