Re: [PATCHES] AllocSetReset improvement

2005-05-16 Thread Karel Zak
On Thu, 2005-05-12 at 11:26 -0400, Tom Lane wrote: I have another idea though: in the case you are looking at, I think that the context in question never gets any allocations at all, which means its blocks list stays null. We could move the MemSet inside the if (blocks) test --- if there are

[PATCHES] farsi faq has not been added yet in website,

2005-05-16 Thread Mahmoud Taghizadeh
would you please fix it, why farsi faq is not in web site?With Regards,--taghi Discover Yahoo! Have fun online with music videos, cool games, IM & more. Check it out!

Re: [PATCHES] AllocSetReset improvement

2005-05-16 Thread a_ogawa
Tom Lane [EMAIL PROTECTED] writes: a_ogawa [EMAIL PROTECTED] writes: It is a reasonable idea. However, the majority part of MemSet was not able to be avoided by this idea. Because the per-tuple contexts are used at the early stage of executor. Drat. Well, what about

Re: [PATCHES] updated GiST patch

2005-05-16 Thread Neil Conway
Neil Conway wrote: This is an updated version of the GiST patch I posted a few months ago. Attached is a revised version. This update fixes some newly-added bugs in mark and restore (I forgot to save and restore the current buffer), and replaces two ReleaseBuffer() + ReadBuffer() pairs with

Re: [PATCHES] updated GiST patch

2005-05-16 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: ... replaces two ReleaseBuffer() + ReadBuffer() pairs with ReleaseAndReadBuffer(). (Is this still worth doing? It seems it no longer saves a lock acquire/release, but perhaps it will again be a win in some future version of the bufmgr...) I think there

Re: [PATCHES] Exec statement logging

2005-05-16 Thread Bruce Momjian
OK, new patch. I used portal-sourceText as Tom suggested, and checked for NULL before printing. I put the original query in brackets in the log output, patch attached. I would like to also do this for server-side EXECUTE. I am have attached a second version that does it by using the existing

Re: [PATCHES] Exec statement logging

2005-05-16 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: a null for the prepare string. Also, rather than change the API for pg_parse_query(), I use a global variable that I check after the function call. This is horribly ugly and will doubtless lead to pfree crashes. What was the point again?

Re: [PATCHES] Exec statement logging

2005-05-16 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: a null for the prepare string. Also, rather than change the API for pg_parse_query(), I use a global variable that I check after the function call. This is horribly ugly and will doubtless lead to pfree crashes. What was the

[PATCHES] Quick little \h enhancement for psql

2005-05-16 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1

Re: [PATCHES] Exec statement logging

2005-05-16 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: What was the point again? Simon said that the EXECUTE is pretty useless for debugging unless we show the prepare query. His patch shows the prepare query for client-side prepare, but not for server side when using the PREPARE/EXECUTE commands ---

Re: [PATCHES] Exec statement logging

2005-05-16 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: What was the point again? Simon said that the EXECUTE is pretty useless for debugging unless we show the prepare query. His patch shows the prepare query for client-side prepare, but not for server side when using the

Re: [PATCHES] updated GiST patch

2005-05-16 Thread Neil Conway
Patch applied. Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: BTW, this idiom occurs a few times: if (BufferIsValid(buf)) { ReleaseBuffer(buf); buf = InvalidBuffer; } I'd leave it as-is; ISTM to be more easily understandable than the alternatives you suggest.

Re: [PATCHES] GiST header cleanup

2005-05-16 Thread Neil Conway
Patch applied. Tom Lane wrote: One objection: I think the GiST amproc numbers (GIST_CONSISTENT_PROC and friends) *are* part of the API and should be in the public header, even if they happen not to be used by any C code at the moment. Ok, I've moved these back to gist.h GISTNStrategies seems