Tom wrote:
> Don't worry, I'll veto any immediate removal of functionality ;-)
> The correct way to handle this is to add some better userlock
> functionality and deprecate what's there. We can remove the crufty
> stuff in a release or three after it's been officially deprecated
> ... but there i
On Tue, May 03, 2005 at 11:43:41PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > I wish you wouldn't since http://rrs.decibel.org uses it.
>
> Don't worry, I'll veto any immediate removal of functionality ;-)
Yes, but will core (or worse, that Bruce guy) over-ride your v
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote:
>> 1998 when the oid played a larger role, it is now quite rightly
>> deprecated and my intention is to remove it from the userlock module.
> I wish you wouldn't since http://rrs.decibel.or
On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote:
> > On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> > Well, there's nothing that says you have to actually refer to locks by
> > name. When I proposed this what I proposed is that the userlock module
> > provide a ded
> On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> Well, there's nothing that says you have to actually refer to locks by
> name. When I proposed this what I proposed is that the userlock module
> provide a dedicated means to map a lock name to a lock number, and
> reserve one of t
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Yep. Actually, the biggest part of this was figuring out what to do
> about the pg_locks view. Since that's basically decided, all that
> remains is to decide what if anything to do about the
> max_locks_per_transaction GUC variable. User locks at t
On Mon, May 02, 2005 at 04:34:50PM -0400, Merlin Moncure wrote:
> Yep. Actually, the biggest part of this was figuring out what to do
> about the pg_locks view. Since that's basically decided, all that
> remains is to decide what if anything to do about the
> max_locks_per_transaction GUC variab
On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> > "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > 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
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 user
> > well, the old ones are GPL. I've made a few attempts to contact the
> > original author...he's MIA. Since 95% of the implementation is in
the
> > backend, it seems odd to have a GPL interface.
>
> I agree. Wasn't it you that was proposing to rewrite the module from
> scratch to eliminate th
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> 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
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> 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
> > 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
> th
"Merlin Moncure" <[EMAIL PROTECTED]> 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. Some
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
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.
>
> Wel
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> So I think we have to maintain the current arrangement
>> of one view, and add enough columns to it to handle all the
>> requirements.
> This seems perfectly ok...as long as there is 1:1 correspondence between
> locktag and lock for all present and f
> In the earlier thread there was talk of separate views for system
> and user locks, but on reflection I think that's the wrong approach;
> principally because it will be impossible to get exactly-simultaneous
> snapshots of the system and user lock states if there are two views
> involved. And t
18 matches
Mail list logo
