Thanks, applied.
---
Florian Pflug wrote:
> On Jul14, 2011, at 22:18 , Bruce Momjian wrote:
> > !OID of the database in which the lock target exists, or
> > !zero if the lock is a shared object, or
> > !
Looks good to me.
---
Florian Pflug wrote:
> On Jul14, 2011, at 22:18 , Bruce Momjian wrote:
> > !OID of the database in which the lock target exists, or
> > !zero if the lock is a shared object, or
> > !
On Jul14, 2011, at 22:18 , Bruce Momjian wrote:
> !OID of the database in which the lock target exists, or
> !zero if the lock is a shared object, or
> !null if the lock is on a transaction ID
For consistency, I think it should say "target" in the second part
of the sentenc
Florian Pflug wrote:
> I still believe the chance of confusion to be extremely small, but since
> you feel otherwise, what about "Targeted" instead of "Locked". As in
>
> OID of the relation targeted by the lock, or null if the lock does not
> target a relation or part of a relation.
>
> Pa
On Jul14, 2011, at 19:06 , Bruce Momjian wrote:
> Florian Pflug wrote:
>> On Jul13, 2011, at 21:08 , Bruce Momjian wrote:
>>> + OID of the relation lock target, or null if the lock is not
>>> on a relation or part of a relation
>>
>> That, however, not so much. "relation lock target" m
Florian Pflug wrote:
> On Jul13, 2011, at 21:08 , Bruce Momjian wrote:
> > - OID of the database in which the object exists, or
> > - zero if the object is a shared object, or
> > - null if the lock object is on a transaction ID
> > + OID of the database in which the lock ta
On Jul13, 2011, at 21:08 , Bruce Momjian wrote:
> - OID of the database in which the object exists, or
> - zero if the object is a shared object, or
> - null if the lock object is on a transaction ID
> + OID of the database in which the lock target exists, or
> + zero
Andrew Dunstan wrote:
>
>
> On 07/13/2011 12:31 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> I think you misunderstood the suggestion. This is not an improvement,
> >>> it's just more confusion.
> >> Well, I thought the "lock on" wording helped avoid the confusion bu
Florian Pflug wrote:
> We could also get rid of the noun completely by saying
>
> (D)
> "Locked page number within the relation, or null if it isn't
>a tuple or relation page that is locked".
>
> I personally slightly favor (D).
I don't think we can use "Locked" here because the lock mig
On 07/13/2011 12:31 PM, Tom Lane wrote:
Bruce Momjian writes:
Tom Lane wrote:
I think you misunderstood the suggestion. This is not an improvement,
it's just more confusion.
Well, I thought the "lock on" wording helped avoid the confusion but
obviously I didn't understand more than that.
Bruce Momjian writes:
> Tom Lane wrote:
>> I think you misunderstood the suggestion. This is not an improvement,
>> it's just more confusion.
> Well, I thought the "lock on" wording helped avoid the confusion but
> obviously I didn't understand more than that. We did have similar
> confusion wh
Florian Pflug wrote:
> On Jul13, 2011, at 17:44 , Tom Lane wrote:
> > Bruce Momjian writes:
> >> OK, I went with this wording, using "lock object is on" terminology.
> >> Applied patch attached --- adjustments welcomed.
> >
> > I think you misunderstood the suggestion. This is not an improvemen
On Jul13, 2011, at 17:44 , Tom Lane wrote:
> Bruce Momjian writes:
>> OK, I went with this wording, using "lock object is on" terminology.
>> Applied patch attached --- adjustments welcomed.
>
> I think you misunderstood the suggestion. This is not an improvement,
> it's just more confusion.
F
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I went with this wording, using "lock object is on" terminology.
> > Applied patch attached --- adjustments welcomed.
>
> I think you misunderstood the suggestion. This is not an improvement,
> it's just more confusion.
Well, I thought the "lock
Bruce Momjian writes:
> OK, I went with this wording, using "lock object is on" terminology.
> Applied patch attached --- adjustments welcomed.
I think you misunderstood the suggestion. This is not an improvement,
it's just more confusion.
regards, tom lane
--
Sent vi
Florian Pflug wrote:
> On Jul11, 2011, at 17:31 , Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Florian Pflug writes:
> >>> On Jul11, 2011, at 17:11 , Tom Lane wrote:
> Yeah, I think this patch is going in the wrong direction altogether.
> It would be better to modify the description of
Bruce Momjian wrote:
> OK, so as I understand it, in pg_locks:
>
> Column | Type | Modifiers
> +--+---
>locktype | text |
>database | oid |
>relation | oid |
>page
On Jul11, 2011, at 17:31 , Bruce Momjian wrote:
> Tom Lane wrote:
>> Florian Pflug writes:
>>> On Jul11, 2011, at 17:11 , Tom Lane wrote:
Yeah, I think this patch is going in the wrong direction altogether.
It would be better to modify the description of virtualtransaction
and pid t
Bruce Momjian writes:
> Tom Lane wrote:
>> Maybe we could just add a paragraph above the "pg_locks Columns" table
>> that says explicitly that virtualtransaction and pid describe the entity
>> holding or awaiting the lock, and the others describe the object being
>> locked? Any way you slice it,
Tom Lane wrote:
> Florian Pflug writes:
> > On Jul11, 2011, at 17:11 , Tom Lane wrote:
> >> Yeah, I think this patch is going in the wrong direction altogether.
> >> It would be better to modify the description of virtualtransaction
> >> and pid to say that those are the "locking" entity.
>
> > H
Tom Lane wrote:
> Florian Pflug writes:
> > On Jul11, 2011, at 05:47 , Bruce Momjian wrote:
> >> Thank you. I think my confusion is that virtualtransaction is the lock
> >> holder/waiter, and the other two are actual locks. The attached doc
> >> patch clarifies that. I had actually realized thi
Florian Pflug writes:
> On Jul11, 2011, at 17:11 , Tom Lane wrote:
>> Yeah, I think this patch is going in the wrong direction altogether.
>> It would be better to modify the description of virtualtransaction
>> and pid to say that those are the "locking" entity.
> Hm, we already kinda of say tha
On Jul11, 2011, at 17:11 , Tom Lane wrote:
> Florian Pflug writes:
>> On Jul11, 2011, at 05:47 , Bruce Momjian wrote:
>>> Thank you. I think my confusion is that virtualtransaction is the lock
>>> holder/waiter, and the other two are actual locks. The attached doc
>>> patch clarifies that. I ha
Florian Pflug writes:
> On Jul11, 2011, at 05:47 , Bruce Momjian wrote:
>> Thank you. I think my confusion is that virtualtransaction is the lock
>> holder/waiter, and the other two are actual locks. The attached doc
>> patch clarifies that. I had actually realized this a few weeks ago and
>> f
On Jul11, 2011, at 05:47 , Bruce Momjian wrote:
> Thank you. I think my confusion is that virtualtransaction is the lock
> holder/waiter, and the other two are actual locks. The attached doc
> patch clarifies that. I had actually realized this a few weeks ago and
> forgot, meaning this is pretty
Florian Pflug wrote:
> On Jul10, 2011, at 06:01 , Bruce Momjian wrote:
> > Can someone help me understand pg_locks? There are three fields related
> > to virtual and real xids:
> >
> > virtualtransaction | text |
> > transactionid | xid |
> > virtualxid | text |
> >
> >
On Jul10, 2011, at 06:01 , Bruce Momjian wrote:
> Can someone help me understand pg_locks? There are three fields related
> to virtual and real xids:
>
> virtualtransaction | text |
> transactionid | xid |
> virtualxid | text |
>
> Our docs say 'virtualtransaction' is:
Can someone help me understand pg_locks? There are three fields related
to virtual and real xids:
virtualtransaction | text |
transactionid | xid |
virtualxid | text |
Our docs say 'virtualtransaction' is:
Virtual ID of the transaction that is holding or awa
28 matches
Mail list logo
