I did manage to get past the stc and src parts
after building wcGTK-2.4.1
cd wxGTK-2.4.1/contrib/stc;make;checkinstall
cd wxGTK-2.4.1/contrib/xrc;make;checkinstall
but got hung up on the make for pgadmin3-0.9.1 here
== CUT of make.log ===
if g++ -DHAVE_CONFIG_H
Larry Rosenman wrote:
--On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Tom Lane writes:
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2
Larry Rosenman wrote:
--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.
Beta2 is a done deal. When Bruce gets
--On Friday, August 29, 2003 22:58:50 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
--On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Tom Lane writes:
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll
--On Friday, August 29, 2003 23:00:46 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to
Does the PG core not care anymore about **QUALITY**?
Ummm, I believe that is why we are still in Beta, and not at a Release
Candidate stage ... cause there are still bugs, with Unixware obviously
being one of them ...
---(end of broadcast)---
--On Saturday, August 30, 2003 00:09:51 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
Does the PG core not care anymore about **QUALITY**?
Ummm, I believe that is why we are still in Beta, and not at a Release
Candidate stage ... cause there are still bugs, with Unixware obviously
being
Larry Rosenman wrote:
Don't start on the SCO issue. I submitted patches last weekend to fix the
UnixWare (and possibly other) issues.
You said you were working on them, then I see the note that BETA2 was tagged
with INVALID shell code in src/templates/unixware, and
the per-platform
--On Friday, August 29, 2003 23:17:50 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
Don't start on the SCO issue. I submitted patches last weekend to fix
the UnixWare (and possibly other) issues.
You said you were working on them, then I see the note that BETA2 was
tagged
So be it, but I was under the impression that the fix would be committed
shortly after I posted it on LAST SATURDAY, but apparently Bruce was out
of town, and the Beta2 TAG was laid, WITHOUT PUBLIC NOTICE about the TAG
coming.
Beta2 TAG was laid so that we could wrap up all fixes to date, of
Larry Rosenman wrote:
--On Friday, August 29, 2003 23:00:46 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
My UnixWare Thread.c
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = $THREAD_CFLAGS -D_REENTRANT
$
note the last line before the prompt.
Check current CVS ... now that Bruce has caught up on his email (or made a
dent in it) after being away, looks like he's committed the fix:
Larry Rosenman wrote:
UnixWare==SCO, but the Court fight has **NOTHING** to do with this issue.
Does the PG core not care anymore about **QUALITY**?
I'm NOT going to stand idly by as the SCO/IBM/RED HAT Legal issues are
used to
hurt PostgreSQL's quality.
I'm NOT very pleased.
Marc G. Fournier wrote:
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = $THREAD_CFLAGS -D_REENTRANT
$
note the last line before the prompt.
Check current CVS ... now that Bruce has caught up on his email (or made a
dent in it) after being away, looks like he's
--On Saturday, August 30, 2003 00:21:29 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = $THREAD_CFLAGS -D_REENTRANT
$
note the last line before the prompt.
Check current CVS ... now that Bruce has caught up on his email (or
--On Friday, August 29, 2003 23:25:06 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Marc G. Fournier wrote:
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = $THREAD_CFLAGS -D_REENTRANT
$
note the last line before the prompt.
Check current CVS ... now that Bruce has
Larry Rosenman wrote:
--On Saturday, August 30, 2003 00:21:29 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = $THREAD_CFLAGS -D_REENTRANT
$
note the last line before the prompt.
Check current CVS ... now
--On Saturday, August 30, 2003 00:19:49 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
So be it, but I was under the impression that the fix would be committed
shortly after I posted it on LAST SATURDAY, but apparently Bruce was out
of town, and the Beta2 TAG was laid, WITHOUT PUBLIC NOTICE
--On Saturday, August 30, 2003 00:35:10 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2003, Larry Rosenman wrote:
--On Saturday, August 30, 2003 00:19:49 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
So be it, but I was under the impression that the fix would be
On Fri, 29 Aug 2003, Larry Rosenman wrote:
Index: src/port/thread.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v
retrieving revision 1.4
diff -u -r1.4 thread.c
--- src/port/thread.c 16 Aug 2003 15:35:51
--On Saturday, August 30, 2003 00:57:45 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2003, Larry Rosenman wrote:
Index: src/port/thread.c
===
RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v
On Fri, 29 Aug 2003, Larry Rosenman wrote:
--On Saturday, August 30, 2003 00:57:45 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Fri, 29 Aug 2003, Larry Rosenman wrote:
Index: src/port/thread.c
===
RCS file:
Mendola Gaetano wrote:
Hi all,
I found this code on the file variables.c and
in the function SetVariable I read:
if (strcmp(current-name, name) == 0)
{
free(current-value);
current-value = strdup(value);
return current-value ? true : false;
}
--On Saturday, August 30, 2003 01:09:54 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first place?
The thing that has me most confused here is that the end result is the
same with or without the patch, from what I can tell ... the
Larry Rosenman wrote:
--On Saturday, August 30, 2003 01:09:54 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first place?
The thing that has me most confused here is that the end result is the
same with or without
On Sat, 30 Aug 2003, Bruce Momjian wrote:
Yes, and that is the complex part because _some_ non-*_r functions are
thread-safe, and some are not. I have to determine if we have other
such platforms before I figure out how to fix it in the cleanest way.
Long shot ... is there some way of
--On Saturday, August 30, 2003 00:17:41 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
--On Saturday, August 30, 2003 01:09:54 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first
place?
The thing that has
Marc G. Fournier wrote:
On Sat, 30 Aug 2003, Bruce Momjian wrote:
Yes, and that is the complex part because _some_ non-*_r functions are
thread-safe, and some are not. I have to determine if we have other
such platforms before I figure out how to fix it in the cleanest way.
Long
Larry Rosenman wrote:
Yes, and that is the complex part because _some_ non-*_r functions are
thread-safe, and some are not. I have to determine if we have other
such platforms before I figure out how to fix it in the cleanest way.
In most platforms that are like this, I think, they have
--On Saturday, August 30, 2003 00:51:01 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
Yes, and that is the complex part because _some_ non-*_r functions are
thread-safe, and some are not. I have to determine if we have other
such platforms before I figure out how to
Bruce Momjian [EMAIL PROTECTED] wrote:
I see other strdup() calls that don't check on a return. Should we deal
with those too?
Well strdup obtain the memory for the new string using a malloc
and normally is a good habit check the return value of a malloc.
Regards
Gaetano Mendola
Gaetano Mendola wrote:
Bruce Momjian [EMAIL PROTECTED] wrote:
I see other strdup() calls that don't check on a return. Should we deal
with those too?
Well strdup obtain the memory for the new string using a malloc
and normally is a good habit check the return value of a malloc.
Right.
Shridhar Daithankar wrote:
Hi all,
Following is from Documentation/vm/overcommit-accounting
-
2 - (NEW) strict overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable percentage (default is
Bruce Momjian [EMAIL PROTECTED] writes:
I see other strdup() calls that don't check on a return. Should we deal
with those too?
strdup - xstrdup if you're concerned.
regards, tom lane
---(end of broadcast)---
TIP 6: Have
Tom Lane wrote:
[EMAIL PROTECTED] writes:
This is on unixware 7 (both 7.3.4 and 7.4b)
I'm on the FR language (I'll re-initdb whith lang=C to see what happens)
Okay. If you find it's still slow in C locale, the next thing to try
would be forcing use of our own qsort, as we already do
You need to allow some head room, I should think. Actually, the
equivalent of the previously discussed paranoid mode would be to set the
percentage to 0, i.e. ensure you can put every page in swap. If you say
50% then the chances of your running out of room are exceedingly small.
andrew
Bruce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've always wanted to be a PoatgreSQL hacker, and I am going to try this
change out first. Bruce said that it's kind of low on the priority list, so
hopefully I won't be holding anyone up if I take a while to get it right.
The bug is that when you
Is there a TODO here? The only problem I see is that it introduces the
idea of special column-1 handling, which we don't have right now, except
in COPY.
---
Andrew Dunstan wrote:
Jon Jensen wrote:
On Thu, 28 Aug 2003,
Marc G. Fournier wrote:
Now, here's a question for someone running a non-FreeBSD OS ... if we were
to jump the BLCKSZ to 16k, would it cause a degradation in performance, or
would it make no difference to them? Would they see an 8% reduction in
performance?
The thing is ... there has been
Thanks to evryone that help on this one.
I reinitdb --locale=C and reloaded everything today.
That did the trick.
However, is there a way to test that strcol is really the culprit?
On Sat, 30 Aug 2003, Bruce Momjian wrote:
Date: Sat, 30 Aug 2003 11:11:11 -0400 (EDT)
From: Bruce Momjian [EMAIL
There is no guarantee that a given sequence is used only for one column
in one table, as I understand it. So renaming it could screw you up badly.
If we made 'serial-ness' first class, and hid the sequence completely
from view, this would make more sense.
Or am I smoking crack?
andrew
On Sat, 30 Aug 2003, Bruce Momjian wrote:
I was thinking the most natural thing would be to use something similar to
COPY's stdin quoting:
CREATE FUNCTION bob() RETURNS INTEGER AS stdin LANGUAGE 'plpgsql';
BEGIN
...
END;
\.
Is there a TODO here? The only problem I see is
Bruce Badger wrote:
What I'd do, if I wanted to lock out old clients from accessing
particular tables, is just rename the tables to something else.
(Or keep using the same names, but put the tables in a schema or
database that old clients won't look in.) The clients wouldn't fail
very
Andrew Dunstan [EMAIL PROTECTED] writes:
There is no guarantee that a given sequence is used only for one column
in one table, as I understand it. So renaming it could screw you up badly.
Yeah, I would recommend having a discussion about the details of the
proposed behavior before you start
On Sat, 30 Aug 2003, Tom Lane wrote:
It'd probably be reasonable to rename only those sequences that are
connected to the target table/column by internal dependencies --- this
indicates that they were created by a SERIAL column definition and not
by manual operations.
I don't understand why
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is there a TODO here? The only problem I see is that it introduces the
idea of special column-1 handling, which we don't have right now, except
in COPY.
I think the idea would be to execute what's effectively a COPY IN during
the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 30 August 2003 09:06, Andrew Dunstan wrote:
There is no guarantee that a given sequence is used only for one column
in one table, as I understand it. So renaming it could screw you up
badly.
If we made 'serial-ness' first class, and
I received this from a friend:
Lance Rushing wrote:
Something bad happened in Postgres. I lost the ability to connect to the
'pegasus2' database.
i was doing some updates when I got an error, saying something about the
backend dying...
When I restarted the database I could no longer connect to
Bruce Momjian [EMAIL PROTECTED] wrote:
Gaetano Mendola wrote:
Bruce Momjian [EMAIL PROTECTED] wrote:
I see other strdup() calls that don't check on a return. Should we
deal
with those too?
Well strdup obtain the memory for the new string using a malloc
and normally is a good habit
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I see other strdup() calls that don't check on a return. Should we deal
with those too?
strdup - xstrdup if you're concerned.
May be is a good idea avoid the future use:
#define strdup
I have done some beta testing with PostgreSQL 7.4beta2.
I have run a simple set of SQL statements 1 million times:
-- START TRANSACTION ISOLATION LEVEL READ COMMITTED;
INSERT INTO t_data (data) VALUES ('2500');
UPDATE t_data SET data = '2500' WHERE data = '2500';
DELETE FROM t_data WHERE data =
On Sat, Aug 30, 2003 at 12:57:26PM -0700, Joe Conway wrote:
Joe Conway wrote:
I don't have any more detail yet on exactly what he was doing at this
point, but I grabbed a copy of $PGDATA and looked at it on my own
machine (since he doesn't have debug and assert support). Logging into
any
Alvaro Herrera wrote:
On Sat, Aug 30, 2003 at 12:57:26PM -0700, Joe Conway wrote:
Joe Conway wrote:
I don't have any more detail yet on exactly what he was doing at this
point, but I grabbed a copy of $PGDATA and looked at it on my own
machine (since he doesn't have debug and assert support).
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think the idea would be to execute what's effectively a COPY IN during
the CREATE FUNCTION command, and then use the data so collected as the
function body. It seems doable offhand, though we'd have to think about
whether this breaks
Gaetano Mendola [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
strdup - xstrdup if you're concerned.
May be is a good idea avoid the future use:
#define strdup STRDUP_DEPRECATED_USE_INSTEAD_XSTRDUP
Not a good idea --- there are places that want to check for strdup
failure and
On Thursday, Aug 28, 2003, at 00:07 America/Chicago, Dennis Björklund
wrote:
On Wed, 27 Aug 2003, Kevin Brown wrote:
There are some cases where it's extremely useful for PostgreSQL to
accept dates of any format it knows about (ambiguities should be
resolved either by looking at the current
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= [EMAIL PROTECTED] writes:
I don't understand why the serial columns sequence should be visible as
other sequences.
Backwards compatibility, if nothing else. Are you prepared to break
every existing dump file that has
CREATE TABLE ser (f1 serial);
Having just had to add serial columns to 3 columns, and found it
moderately painful, I have had these thoughts:
. We need alter table foo add column bar serial - wasn't someone
working on that?
. What about a rowid type? Wouldn't have to be in any order, just
unique. Could be an existing OID
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
The interesting thing was that my postmaster needed around 4mb of RAM
when I started running my test script using ...
After about 2 1/2 hours the backend process already needed 11mb of ram.
Hmm. I tried
create table t_data
On Sat, 30 Aug 2003, Tom Lane wrote:
I don't understand why the serial columns sequence should be visible as
other sequences.
Backwards compatibility, if nothing else. Are you prepared to break
every existing dump file that has
CREATE TABLE ser (f1 serial);
SELECT
60 matches
Mail list logo
