From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Questionable codes |
Date: | 1999-12-14 16:23:24 |
Message-ID: | 15564.945188604@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> I have found a few questionable codings. I'm not sure if it really
> hurts anything. Suggestions are welcome.
> 1) in storage/lmgr/lock.c: LockShmemSize()
> size += MAXALIGN(maxBackends * sizeof(PROC)); /* each MyProc */
> size += MAXALIGN(maxBackends * sizeof(LOCKMETHODCTL)); /* each
> shouldn't be:
> size += maxBackends * MAXALIGN(sizeof(PROC)); /* each MyProc */
> size += maxBackends * MAXALIGN(sizeof(LOCKMETHODCTL)); /* each
Probably, but I'm not sure it really makes any difference. We add on
10% or so slop after we've finished adding up all these numbers, anyway
;-)
> 2) in utils/hash/dynahash.c:hash_search():
> Assert(saveState.currElem && !(saveState.currElem = 0));
> Does anybody know what it is for?
That's part of that horribly ugly, non-reentrant HASH_REMOVE_SAVED
interface, isn't it? I have a to-do item to rip that code out and
replace it with a more reasonable design ... in the meantime, I don't
think it much matters whether the Assert could be tightened up ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-12-14 16:25:10 | Re: [HACKERS] Questionable codes |
Previous Message | Karel Zak - Zakkr | 1999-12-14 14:54:10 | Re: [HACKERS] Datatype MONEY |