Rodrigo Sakai wrote:
Hello,
I’m having a big trouble with the index size! I have looked for a
solution in the internet, but the solutions that I found don’t fit for me!
I would guess you have an allocation calculation error/memory leak
somewhere in your implementation - maybe post a
"Rodrigo Sakai" <[EMAIL PROTECTED]> writes:
> I developed a new data type using C and add this new type on PostgreSQL.
> Basically, the data type is: (DateADT, DateADT) with some temporal rules
> that I'm researching! The data type is ok; the in, out, receive and send
> functions are ok; some ope
Hello,
I'm having a big trouble with the index size! I have looked for a solution
in the internet, but the solutions that I found don't fit for me!
I developed a new data type using C and add this new type on PostgreSQL.
Basically, the data type is: (DateADT, DateADT) with some temporal
Magnus Hagander wrote:
My second thought is that we should quite possibly abandon this
translation altogether - we know that our COPY code is quite happy with
either style of line ending, as long as the file is consistent, and also
many Windows programs will quite happily read files with Unix s
All,
Following some public and not so public discussion a little while back,
I decided to ask a group of people to help me to create an
experimental tracker instance for bugs and possibly features, to assist
our development efforts. The people I chose were some I have worked with
before, e.g
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Is there a reasonable way to treat libstemmer as an external library?
> Hmmm ... do we want to do that if we're distributing it in core? That
> would require us to have a --with-tsearch compile switch so that people
> who don't want to find & build lib
Tom,
> Is there a reasonable way to treat libstemmer as an external library?
Hmmm ... do we want to do that if we're distributing it in core? That
would require us to have a --with-tsearch compile switch so that people
who don't want to find & build libstemmer can build PostgreSQL. I thought
I notice that in 8.3, when I kill the postmaster process with SIGKILL or
SIGSEGV, the child processes writer and stats collector go away
immediately, but the autovacuum launcher hangs around for up to a
minute. (I suppose this has to do with the periodic wakeups?). When
you try to restart the
Michael Paesold wrote:
> In case of recovery, I think one should still get the full
> output, no?
Recovery happens just after these messages are printed, so the window
when they are actually relevant would be very small.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
While looking at the tsearch-in-core patch I was distressed to notice
that a good fraction of it is derived files, bearing notices such as
/* This file was generated automatically by the Snowball to ANSI C compiler */
Our normal policy is "no derived files in CVS", so I went looking to
see if we
Tasneem,
> > The margins to the op2, i.e. m1 and m2, are added dynamically on
> > both the sides, considering the value it contains. To keep this
> > margin big is important for a certain reason discussed later.
> > The NEAR operator is supposed to obtain the values near to the op2,
> > thus
> CC: pgsql-hackers@postgresql.org> From: [EMAIL PROTECTED]> Subject: Re:
> [HACKERS] To all the pgsql developers..Have a look at the operators proposed
> by me in my research paper.> Date: Fri, 1 Jun 2007 19:13:54 -0500> To: [EMAIL
> PROTECTED]> > On Jun 1, 2007, at 8:24 AM, Tasneem Memon wrot
On 6/2/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
On further consideration I don't see the necessity for this. We don't
say this about lib-ossp-uuid although it too is only used for a contrib
module.
And is it good? For that functionality I would also add comment
describing that this "--with
Nikolay Samokhvalov wrote:
On 6/2/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
On further consideration I don't see the necessity for this. We don't
say this about lib-ossp-uuid although it too is only used for a contrib
module.
And is it good? For that functionality I would also add commen
Does anyone object if I change these two config help lines:
--enable-thread-safety-force force thread-safety in spite of thread
test failure
--with-krb-srvnam=NAME name of the default service principal in
Kerberos [postgres]
to:
--enable-thread-safety-force force thread-safety de
Andrew Dunstan wrote:
Nikolay Samokhvalov wrote:
The current CVS' configure is really confusing: it has "--with-xslt"
option, while there is no XSLT support in the core. At least let's
change the option's comment to smth like "build with XSLT support (now
it is used for contrib/xml2 only)".
"Joe Conway" <[EMAIL PROTECTED]> writes:
> Sorry for my ignorance, but I haven't been able to keep up lately --
> what is the difference between pg_detoast_datum_packed and pg_detoast_datum,
> and how do I know when to use each? E.g. I notice that the related macro
> PG_GETARG_TEXT_PP is used in
17 matches
Mail list logo
