I've put my 2 pending 7.4Beta2 Patches up on my website at:
http://www.lerctr.org/~ler/postgresql/
the unixware.thread.patch file is the bits needed to allow
--enable-thread-safety
to work.
the unixware.shlib.patch file places an absolute pathname in DT_SONAME for
the shared library. this will
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "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 i
> > Backwards compatibility, if nothing else. Are you prepared to break
> > every existing dump file that has
> > CREATE TABLE ser (f1 serial);
> > SELECT pg_catalog.setval('ser_f1_seq', 1, false);
>
> I think breaking backward compability not always bad. If
Replacing SERIAL with a GENER
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 p
=?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_d
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
Joe Conway <[EMAIL PROTECTED]> writes:
> Fortunately this was his own development database he was messing with,
> but it was an interesting exercise none-the-less. Maybe this reinforces
> the need to have a command for enabling/disabling triggers.
No, it reinforces the cardinal rule about not ex
=?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);
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 DateS
"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
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 th
Bruce Momjian wrote:
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 50) of physical
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). L
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
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 other database works fine, but the offending database produces this
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 = '25
Dennis Björklund wrote:
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.
"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 STRDUP_DEPRECA
"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 nor
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 my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 30 August 2003 09:38, Tom Lane wrote:
> 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
-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, a
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 du
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 w
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
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
>
There's certainly a TODO, but I'm not yet 100% sure that the solution
Jon proposed is best. I'm looking at it as we write, and making it work
looks to be somewhat complex. If we go that road we would probably need
to generalise somewhat the COPY code.
The alternative in my mind is some function
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? Th
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
Jonatha
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 CREATE FUNCTION com
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
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
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 200
-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 c
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
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 alrea
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:
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 (defa
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
"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
--
--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 t
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,
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.
--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
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 wr
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
--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 ...
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 : f
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
> >> =
--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
ret
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:
--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 woul
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 committed
> >> shortly after I posted it on LAST SATURDAY, but apparently Bruce
--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 NOTI
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.
--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
--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 (
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,
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.
> >>
> >
> 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:
SUPPORT
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]> wr
> 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,
--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
tagge
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 th
--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
> 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)---
T
--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
--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
>
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
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 o
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 -
71 matches
Mail list logo
