Re: [PATCHES] trivial refactoring of WaitOnLock

2005-03-10 Thread Neil Conway
Neil Conway wrote: memcpy(new_status, old_status, len) would be faster yet. Which is what I originally implemented, and then decided the sprintf() was clearer (since performance isn't very important here). On reflection, memcpy() + strcpy() should be fine; I'll commit this tomorrow. Applied. -Ne

Re: [PATCHES] trivial refactoring of WaitOnLock

2005-03-09 Thread Neil Conway
Russell Smith wrote: *** 1083,1091 locallock->lock, locallock->tag.mode); old_status = pstrdup(get_ps_display()); ! new_status = (char *) palloc(strlen(old_status) + 10); strcpy(new_status, old_status); ! strcat(new_status, " waiting");

Re: [PATCHES] trivial refactoring of WaitOnLock

2005-03-09 Thread Qingqing Zhou
Yes, reduced one round of counting the length of new_status. "Russell Smith" <[EMAIL PROTECTED]> > If the problem is speed, then this may be faster. > > > Index: src/backend/storage/lmgr/lock.c > === > RCS file: /projects/cvsroot/pgs

Re: [PATCHES] trivial refactoring of WaitOnLock

2005-03-09 Thread Russell Smith
If the problem is speed, then this may be faster. Index: src/backend/storage/lmgr/lock.c === RCS file: /projects/cvsroot/pgsql/src/backend/storage/lmgr/lock.c,v retrieving revision 1.147 diff -c -r1.147 lock.c *** src/backend/storage

Re: [PATCHES] trivial refactoring of WaitOnLock

2005-03-08 Thread Qingqing Zhou
off-by-one is true, but I am not sure if the revised code is faster. sprintf() need the extra job to parse the format. In win32, I am sure it is much slower. "Neil Conway" <[EMAIL PROTECTED]> news:[EMAIL PROTECTED] > This patch refactors some code in WaitOnLock slightly. The old code was > sl

[PATCHES] trivial refactoring of WaitOnLock

2005-03-08 Thread Neil Conway
This patch refactors some code in WaitOnLock slightly. The old code was slow, and I believe it was off-by-one (it allocates one byte of memory more than needed). Barring any objections I'll apply this to HEAD later today. -Neil Index: src/backend/storage/lmgr/lock.c =