> "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
> wha
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 bec
"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 hol
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 an
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 i
"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?
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 th
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
"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
> > [ 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 incorpora
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 wou
"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
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 luck
13 matches
Mail list logo
