[ yawn... ] Create a table with a name column, put some rows in
it,
lock the rows.
What would guarantee that the OIDs of those rows don't conflict with
some other OIDs in the system?
BTW, this becomes a real issue if you're trying to write code that is
meant to be incorporated into
Merlin Moncure [EMAIL PROTECTED] 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
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] 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
On Tue, Jan 25, 2005 at 01:51:27PM -0500, Merlin Moncure wrote:
Merlin,
2. (proposing) new system type that covers the maximum bitspace allowed
inside locktag structure, and add a union here to reduce confusion
(encompassing offsetnum but not lockmethodid).
Please search this message in the
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
Tgl wrote:
[ 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
On Tue, Jan 25, 2005 at 08:19:05AM -0500, Merlin Moncure wrote:
[ yawn... ] Create a table with a name column, put some rows in
it,
lock the rows.
What would guarantee that the OIDs of those rows don't conflict with
some other OIDs in the system?
BTW, this becomes a real issue
Merlin Moncure [EMAIL PROTECTED] writes:
Is it possible for one backend (with superuser privs) to release a
lock
held by anotether?
As of 8.0 this is not possible for regular locks, because there'd be
no
way to update the other backend's internal data structure that shows
what locks it
Alvaro wrote:
Please search this message in the archives:
right. heh. Well, moving on...
tgl wrote:
Since subids and offnums are only 16 bits, we could pack all of these
cases into 64 bits with a 16-bit type identifier to distinguish the
cases. That would mean that LOCKTAG doesn't get any
Merlin Moncure [EMAIL PROTECTED] writes:
Is it possible for one backend (with superuser privs) to release a lock
held by anotether?
As of 8.0 this is not possible for regular locks, because there'd be no
way to update the other backend's internal data structure that shows
what locks it holds.
Ok,
With 8.0 out the door, I'd like to reopen discussion re: userlock
contrib. module and propose to get it moved into the core database
sources. This was discussed a bit a few months back but it never made
it officially to the todo list. I'm not sure what the final consensus
was on the shared
Speaking of other tricks and things missing; I'd like to see support for
named locks. If you're using locks for something other than row-level
locking, it's awkward at best to have to come up with an OID to identify
your lock with, and even that doesn't guarantee uniqueness. You're also
out of
Jim C. Nasby [EMAIL PROTECTED] writes:
Speaking of other tricks and things missing; I'd like to see support for
named locks.
[ yawn... ] Create a table with a name column, put some rows in it,
lock the rows.
regards, tom lane
---(end of
On Mon, Jan 24, 2005 at 10:43:40PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Speaking of other tricks and things missing; I'd like to see support for
named locks.
[ yawn... ] Create a table with a name column, put some rows in it,
lock the rows.
What would guarantee
14 matches
Mail list logo
