> Tatsuo Ishii wrote:
> > > Tatsuo, are you planning to add this to CVS HEAD?
> >
> > Yes, I would like to add if there's no objection.
>
> I have heard no comment, and it looks useful, so please add it at your
> convenience.
Ok, done.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> -
Tatsuo Ishii wrote:
> > Tatsuo, are you planning to add this to CVS HEAD?
>
> Yes, I would like to add if there's no objection.
I have heard no comment, and it looks useful, so please add it at your
convenience.
---
> --
>
> Tatsuo, are you planning to add this to CVS HEAD?
Yes, I would like to add if there's no objection.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> ---
>
> Tatsuo Ishii wrote:
> > I have attached pgrowlocks tested under current.
> >
Tatsuo, are you planning to add this to CVS HEAD?
---
Tatsuo Ishii wrote:
> I have attached pgrowlocks tested under current.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
>
> > Tatsuo, have you developed a new version of this f
I have attached pgrowlocks tested under current.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Tatsuo, have you developed a new version of this for 8.2?
>
> ---
>
> Tatsuo Ishii wrote:
> > > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
Tatsuo, have you developed a new version of this for 8.2?
---
Tatsuo Ishii wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > To accomplish this I need to add following function into
> > > storage/ipc/procarray.c. Thi
> On Fri, Aug 19, 2005 at 09:19:24PM +0900, Tatsuo Ishii wrote:
> > > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > > To accomplish this I need to add following function into
> > > > storage/ipc/procarray.c. This is similar to BackendPidGetProc() except
> > > > that it accepts xid as an argument.
On Fri, Aug 19, 2005 at 09:19:24PM +0900, Tatsuo Ishii wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > To accomplish this I need to add following function into
> > > storage/ipc/procarray.c. This is similar to BackendPidGetProc() except
> > > that it accepts xid as an argument. Any object
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > To accomplish this I need to add following function into
> > storage/ipc/procarray.c. This is similar to BackendPidGetProc() except
> > that it accepts xid as an argument. Any objection?
>
> > if (xid == 0) /* never match
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> To accomplish this I need to add following function into
> storage/ipc/procarray.c. This is similar to BackendPidGetProc() except
> that it accepts xid as an argument. Any objection?
> if (xid == 0) /* never match dummy PGP
> Should this functionality be moved into the backend? When?
Since feature freeze for 8.1 has been already made, I think this
should be into 8.2 or later if necessary.
BTW, I have modified pgrowlocks so that it shows pids:
test=# select * from pgrowlocks('t1');
locked_row | lock_type | locker
Should this functionality be moved into the backend? When?
---
Tatsuo Ishii wrote:
> > On Fri, Aug 12, 2005 at 02:08:29PM +0900, Tatsuo Ishii wrote:
> > > > On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
> >
> On Fri, Aug 12, 2005 at 02:08:29PM +0900, Tatsuo Ishii wrote:
> > > On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
> > >
> > > > However even one of transactions, for example 647 commits, still it
> > > > shows as if 647 is a member of muitixid 3.
> > > >
> > > > test=# select *
On Fri, Aug 12, 2005 at 02:08:29PM +0900, Tatsuo Ishii wrote:
> > On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
> >
> > > However even one of transactions, for example 647 commits, still it
> > > shows as if 647 is a member of muitixid 3.
> > >
> > > test=# select * from pgrowlock
> On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
>
> > However even one of transactions, for example 647 commits, still it
> > shows as if 647 is a member of muitixid 3.
> >
> > test=# select * from pgrowlocks('t1');
> > locked_row | lock_type | locker | multi | xids
> > ---
On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
> However even one of transactions, for example 647 commits, still it
> shows as if 647 is a member of muitixid 3.
>
> test=# select * from pgrowlocks('t1');
> locked_row | lock_type | locker | multi | xids
> +--
> Hi,
>
> With a help from Bruce, I wrote a small function which returns row
> locking information(see attached file if you are interested). Here is
> a sample result:
>
> test=# select * from pgrowlocks('t1');
> locked_row | lock_type | locker | multi
> +---++--
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> All in all, Tatsuo is right in that there's no way to know what tuples
> are locked without scanning the whole table.
Sure. I was just questioning how much one needs to know that. It seems
to me that the only time you really care is when you are inves
On Sun, Aug 07, 2005 at 09:46:08PM +0900, Tatsuo Ishii wrote:
> With a help from Bruce, I wrote a small function which returns row
> locking information(see attached file if you are interested).
A quick note: it's easier to build tuples using heap_form_tuple instead
of BuildTupleFromCStrings.
--
On Mon, Aug 08, 2005 at 10:26:12AM -0400, Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > If I understand correctly, it seems the above method does show a
> > locked row's TID which does not block someone else. That is a little
> > bit different from what I expcted.
>
> Well, it *co
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > If I understand correctly, it seems the above method does show a
> > locked row's TID which does not block someone else. That is a little
> > bit different from what I expcted.
>
> Well, it *could* be blocking someone else. If there were more than on
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> If I understand correctly, it seems the above method does show a
> locked row's TID which does not block someone else. That is a little
> bit different from what I expcted.
Well, it *could* be blocking someone else. If there were more than one
waiter for
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > With a help from Bruce, I wrote a small function which returns row
> > locking information(see attached file if you are interested).
>
> Scanning the whole table seems a bit slow :-(
Yes, but I couldn't find any other way.
> There is another possibi
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> With a help from Bruce, I wrote a small function which returns row
> locking information(see attached file if you are interested).
Scanning the whole table seems a bit slow :-(
There is another possibility: in CVS tip, anyone who is actually blocked
on a
24 matches
Mail list logo
