SEO

Tom Lane wrote:
> > This seems perfectly ok...as long as there is 1:1 correspondence
between
> > locktag and lock for all present and future types of locks. I'd
like to
> > point out though that when querying for user locks it's kind of nice
not
> > to wade through transaction locks, etc.
>
> Well, sure, but that's what "SELECT ... WHERE" is for ;-)

yeah, I misread your earlier post...being able to filter on lock type
(or not) is an ideal solution. So, pg_locks it is.

I'd also like to make one more comment:
> This still leaves us with the issue of what to do with user locks.
> I am inclined to display them as if they were OBJECT locks, ie, fill
> the database, classid, objid, and objsubid columns. An alternative
> that would also expose all the info is to display them as if they
> were TUPLE locks. Or we could add still more columns, but I'm not
> real enthused about that idea.

I don't like the idea of listing user locks with 'tuple' locks for no
other reason than this might confuse what user locks are. Even though
they will be used as tuple locks 99% of the time, user locks are only
loosely coupled with tuples in part because there is no sytem generated
column which is persistent and > 32 bits. IMO, this is a problem with
the current user lock module...it encourages locking over oid which is a
bad practice. A properly implemented user lock system would likely
maintain a global sequence shared by all lockable objects, tuple or
otherwise.

Listing them as object locks seems ok.

Merlin



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Mon, May 02, 2005 at 01:12:06PM -0400, Merlin Moncure wrote:

> I don't like the idea of listing user locks with 'tuple' locks for no
> other reason than this might confuse what user locks are. Even though
> they will be used as tuple locks 99% of the time, user locks are only
> loosely coupled with tuples in part because there is no sytem generated
> column which is persistent and > 32 bits. IMO, this is a problem with
> the current user lock module...it encourages locking over oid which is a
> bad practice.

Another way would be to allow user locks to use the four fields of
LOCKTAG. So the user would be able to establish more powerful
conventions: say the relation's Oid, and a related sequence value if
there is one; or a blocknumber/offset (ctid) if there isn't, etc.

> A properly implemented user lock system would likely
> maintain a global sequence shared by all lockable objects, tuple or
> otherwise.

That'd just be equivalent to require that user tables are created WITH
OIDS, only the counter wouldn't be shared with system tables ... how is
that any better?

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Ellos andaban todos desnudos como su madre los parió, y también las mujeres,
aunque no vi más que una, harto moza, y todos los que yo vi eran todos
mancebos, que ninguno vi de edad de más de XXX años" (Cristóbal Colón)

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> I don't like the idea of listing user locks with 'tuple' locks for no
> other reason than this might confuse what user locks are.

Fair enough, although I think that at least one major application of
user locks would be equivalent to tuple locks. Somebody was asking
for named user locks in the previous thread, and the easiest way to
get that is to make a table containing just lock names, and then lock
on the CTIDs of that table. Since there would be no reason to allow
UPDATE or DELETE in such a table, the putative instability of CTID
doesn't really matter.

However, displaying them as object locks certainly works, and you'd have
to put some intelligence in front of the view anyway about what meaning
you were assigning to user locks in your installation. So you can
always cast to whatever you need.

> IMO, this is a problem with the current user lock module...it
> encourages locking over oid which is a bad practice. A properly
> implemented user lock system would likely maintain a global sequence
> shared by all lockable objects, tuple or otherwise.

Certainly the current contrib/userlock code could stand a rewrite.
Or more likely, addition of new functions --- we should deprecate
the old ones, but I see no need to remove 'em right away.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

FWIW, I've asked previously for a means to name userlocks. The reason
for this is that if you're not locking on some kind of object with an
OID then you're stuck picking some random value and hoping that no one
else using userlock ever picks the same value. If instead there was a
means to name userlocks, it's easy to use a name like "My application:
some thing I want to block on". Putting the 'My application:' in there
pretty much ensures that you won't conflict with anything else, and the
randomness of whatever you call what you're locking on should be plenty
to handle the rest.

On Mon, May 02, 2005 at 01:30:49PM -0400, Tom Lane wrote:
> "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > I don't like the idea of listing user locks with 'tuple' locks for no
> > other reason than this might confuse what user locks are.
>
> Fair enough, although I think that at least one major application of
> user locks would be equivalent to tuple locks. Somebody was asking
> for named user locks in the previous thread, and the easiest way to
> get that is to make a table containing just lock names, and then lock
> on the CTIDs of that table. Since there would be no reason to allow
> UPDATE or DELETE in such a table, the putative instability of CTID
> doesn't really matter.
>
> However, displaying them as object locks certainly works, and you'd have
> to put some intelligence in front of the view anyway about what meaning
> you were assigning to user locks in your installation. So you can
> always cast to whatever you need.
>
> > IMO, this is a problem with the current user lock module...it
> > encourages locking over oid which is a bad practice. A properly
> > implemented user lock system would likely maintain a global sequence
> > shared by all lockable objects, tuple or otherwise.
>
> Certainly the current contrib/userlock code could stand a rewrite.
> Or more likely, addition of new functions --- we should deprecate
> the old ones, but I see no need to remove 'em right away.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match