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 ther
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!
(BTom Lane <[EMAIL PROTECTED]> writes:
(B> a_ogawa <[EMAIL PROTECTED]> writes:
(B> > It is a reasonable idea. However, the majority part of MemSet was not
(B> > able to be avoided by this idea. Because the per-tuple contexts are used
(B> > at the early stage of executor.
(B>
(B> Drat. Well
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
Rele
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
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
Bruce Momjian 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?
rega
Tom Lane wrote:
> Bruce Momjian 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?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Bruce Momjian 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
Agreed, it needs work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached are some tab-completion enhancements for psql. In rough order,
they are:
* Made DELETE into "DELETE FROM"
* Moved ANALZYE to the end of the list to ease EXPLAIN / VACUUM
conflicts
* Removed the ANALYZE xx semicolon completion: we don'
Greg Sabino Mullane wrote:
Attached are some tab-completion enhancements for psql.
Barring any objections I'll apply this later today or tomorrow.
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Bruce Momjian 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 --- seems we should
Tom Lane wrote:
> Bruce Momjian 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
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.
This patch moves GiST implementation details from gist.h into a new
header file, gist_private.h. gist.h should only contain APIs that are
exposed to clients writing GiST extensions -- where possible we should
avoid backward-incompatible changes to those APIs, so it makes sense to
keep that API
Neil Conway <[EMAIL PROTECTED]> writes:
> This patch moves GiST implementation details from gist.h into a new
> header file, gist_private.h.
Sounds reasonable. The other index AMs could possibly benefit from the
same thing --- in particular I believe nbtree.h is included by quite a
lot of places
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 inhere
I asked the list to update the webite and add link for farsi FAQ.
I dont know why web site maintainer has not fixed it.
Is it necessary to update farsi FAQ for new version of postgresql so that it can be added in web site?
With Regards,--taghi
Do you Yahoo!?
Yahoo! Mail - Find what you need w
19 matches
Mail list logo
