going to be dealing with this this weekend ... Bruce already asked me as
well, just been busy during the week, so had to defer to the weekend ...
if its not in place by tomorrow around, so, 8pm GMT,please feel free to
email-nag me :)
On Fri, 18 Oct 2002, Michael Meskes wrote:
Could anyone
On 18 Oct 2002 at 18:10, Ulrich Neumann wrote:
Marc,
not only the global variables are a problem. PostgreSQL doesn't clean
up
all the memory before a process terminates and you must deal with
signals between threads.
OK, first of all let me say this. I am interested in seeing postgresql
Dann Corbit [EMAIL PROTECTED] writes:
I am curious as to why it is necessary to add PL/pgSQL as a language
instead of including it by default.
I believe security was one of the reasons.
regards, tom lane
---(end of
I am curious as to why it is necessary to add PL/pgSQL as a language
instead of including it by default.
Is it to save space on small systems or???
Since the code necessary PL/pgSQL is very small, it does not seem like
there would be much savings. I imagine that there is occasionally some
Bruce Momjian [EMAIL PROTECTED] writes:
I am concerned that removing them may cause instability, particularly in
some of the java build scripts. That's why I am suggesting not doing it
during beta.
Actually, it looks to me like they belong with the JDBC driver. As long
as JDBC is in the main
I notice there's a leak of memory in SPI_prepare().
The full fix is nontrival and I don't want to submit a half solution so I
thought I'd check whether people think it's worth worrying about.
The leak is that memory is grabbed in SPI_prepare() for a plan within whatever
context is current when
On Sat, 19 Oct 2002, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
The leak is that memory is grabbed in SPI_prepare() for a plan within
whatever context is current when it does the palloc(). It may be the
caller's or it may be the relevent SPI one. The plan is then copied
Nigel J. Andrews [EMAIL PROTECTED] writes:
On Sat, 19 Oct 2002, Tom Lane wrote:
I'm not sure where the leak is in your plpython example, but I'd be
inclined to look to plpython itself, perhaps even just the string
concatenation expression in
plan = plpy.prepare(SELECT + repr(a))
Well it's
On Fri, 18 Oct 2002, Mike Mascari wrote:
Gavin Sherry wrote:
On Fri, 18 Oct 2002, Tom Lane wrote:
Anyone see a way out of this catch-22? If not, which is the least
bad alternative?
Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
I know :-).
On Fri, 2002-10-18 at 22:03, Marc G. Fournier wrote:
On Fri, 18 Oct 2002, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Larry Rosenman wrote:
Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
by).
I can confirm that:
On Fri, 18 Oct 2002, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Larry Rosenman wrote:
Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
by).
I can confirm that:
http://ftp.gnu.org/gnu/bison/
Attached is the Changelog since 1.50.
Urgh. Nothing
On Fri, Oct 18, 2002 at 10:28:38AM -0400, Tom Lane wrote:
Greg Copeland [EMAIL PROTECTED] writes:
On Thu, 2002-10-17 at 22:20, Tom Lane wrote:
Simple: respond to 'em all with a one-line answer: convince us why we
should use it. The burden of proof always seems to fall on the wrong
end in
At 12:07 AM 19/10/2002 +0200, Peter Eisentraut wrote:
Any old machine has a 4-byte off_t if you configure with
--disable-largefile.
Thanks - done. I just dumped to a custom backup file, then dumped it do
SQL, and compared each version (V7.2.1, 8 byte 4 byte offsets), and they
all looked OK.
I have put the latest patch at:
http://downloads.rhyme.com.au/postgresql/pg_dump/
along with two dump files of the regression DB, one with 4 byte
and the other with 8 byte offsets. I can read/restore each from
the other, so it looks pretty good. Once the endianness is tested,
we should be
Bruce Momjian [EMAIL PROTECTED] writes:
I think we should move /contrib/retep to gborg. It is 400k and isn't
anywhere near our core functionality. I will add to TODO:
Move /contrib/retep to gborg
Can I move this during beta? I don't think so.
Why not?
Feature addition during beta is
Peter Eisentraut wrote:
Teodor Sigaev writes:
wow=# select 5.3::float;
ERROR: Bad float8 input format '5.3'
Does it accept '5,4'::float?
Yes, it accepted '5,4'::float format.
--
Teodor Sigaev
[EMAIL PROTECTED]
---(end of
Bruce Momjian [EMAIL PROTECTED] writes:
Michael, please use bison 1.75 to update ecpg
Why is this necessary? AFAIK we don't keep bison-derived files in
CVS...
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
---(end of
Anuradha Ratnaweera [EMAIL PROTECTED] writes:
Let me explain my posting which started this `thread':
- The developer's FAQ section 1.9 explains why PostgreSQL doesn't use
threads (and many times it has been discussed on the list).
- The TODO list has an item `Experiment with multi-threaded
Neil Conway wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Michael, please use bison 1.75 to update ecpg
Why is this necessary? AFAIK we don't keep bison-derived files in
CVS...
Right, they aren't in CVS, but they are shipped in the tarball so we
don't require everyone to have bison.
-Original Message-
From: Tom Lane [mailto:tgl;sss.pgh.pa.us]
Sent: 19 October 2002 17:17
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] /contrib/retep to gborg
Bruce Momjian [EMAIL PROTECTED] writes:
I am concerned that removing them may cause
20 matches
Mail list logo
