Alvaro Herrera wrote:
Pavel Stehule wrote:
On 01/11/2007, Tom Lane [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
When I try manually rebuild cluster I had second problem:
C:\PostgreSQL\bininitdb -D ../data
The program postgres is needed by initdb but was not found in the
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
My question is -hackers, is who wants first bite and what do they
want :)
Something I'd like to have back real soon is the daily DBT run against
CVS HEAD that Mark Wong was doing at OSDL. Maybe we don't need a
particularly
On Tue, 9 Oct 2007 13:16:08 -0400
D'Arcy J.M. Cain [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007 19:02:38 +0200
Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Dienstag, 9. Oktober 2007 schrieb D'Arcy J.M. Cain:
+ Due to locale changes this type may have problems with dump and
+ restore
Hi Tom et all!
Thanks for your mails.
On Fri, 2 Nov 2007, Tom Lane wrote:
Date: Fri, 02 Nov 2007 16:08:24 -0400
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Heikki Linnakangas [EMAIL PROTECTED],
pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] should
Hello.
I compiled and installed PostgreSQL 8.3 beta 2 on OS X 10.4.10 these days,
and noticed a minor issue that may lead to some problems, occasionally.
I generally run make check, and that consumes some extra disk space, of
course. While versions 8.1 and 8.2 were quite happy with a total of
[EMAIL PROTECTED] writes:
I'm confused, until I have clearence to send the schema, here are pg logs:
Nov 3 14:44:20 sun postgres[17963]: [189-1] ERROR: trigger unnamed for
relation objets already exists
Nov 3 14:44:20 sun postgres[17963]: [189-2] STATEMENT: CREATE CONSTRAINT
TRIGGER
Sorry to post on my own post,
I found this (as a little exemple I've got plenty of these)
could that be the culprit and how to correct that?
--
-- Name: RI_ConstraintTrigger_609094000; Type: TRIGGER; Schema: public; Owner:
delain
--
CREATE CONSTRAINT TRIGGER unnamed
AFTER DELETE ON objets
J=?ISO-8859-1?B?9g==?=rg Beyer [EMAIL PROTECTED] writes:
I generally run make check, and that consumes some extra disk space, of
course. While versions 8.1 and 8.2 were quite happy with a total of
approximately 280-300 MB of free disk space for the build, 8.3 beta 2
consumes *up to 1.6
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
I never received a response on this. Here is the full diff with the
above change. Since it is documentation and not code, is it OK to
commit this now?
The added text needs some copy-editing, I think. How about
Since the output of this data
Tom Lane [EMAIL PROTECTED] writes:
A more direct approach to the problem might be to change pg_dump to
set lc_monetary, as it does for client_encoding ...
It should probably note that if the machine being restored onto has a
different libc it could still not be restorable even with the correct
Back when we agreed that we should treat CREATE CONSTRAINT TRIGGER as a
documented, non-deprecated user command, I made a change so that it
would use the specified name as the actual name of the trigger in
pg_trigger. Pre-8.3 releases would auto-generate sorta-unique names of
the form
On Sat, 03 Nov 2007 14:39:48 -0400
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
I never received a response on this. Here is the full diff with the
above change. Since it is documentation and not code, is it OK to
commit this now?
The added text needs
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Brendan Jurd wrote:
As discussed on -hackers, I'm trying to get rid of some redundant code
by creating a widely
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
A more direct approach to the problem might be to change pg_dump to
set lc_monetary, as it does for client_encoding ...
Certainly OK by me.
Greg's objection caused me to rethink that. Doing it would be a problem
Tom Lane wrote:
Doing it would be a problem
when transporting dump files across platforms: what if the
appropriate locale name is spelled differently on the new machine?
The question is which is more likely?
Using a dump on a similar platform with different locale settings is
fairly common,
On Sat, 3 Nov 2007, Tom Lane wrote:
Date: Sat, 03 Nov 2007 12:42:24 -0400
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Heikki Linnakangas [EMAIL PROTECTED],
pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] should I worry?
[EMAIL PROTECTED] writes:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Ok, this
I wrote:
4. Try to auto-update inside the backend. I don't have an exact
proposal for how this would work, but I'm thinking in terms of having
the conversion key off CREATE CONSTRAINT TRIGGER commands referencing
one of the built-in RI_FKey_xxx trigger functions. The tricky part here
is
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Andrew Dunstan wrote:
Peter Eisentraut wrote:
Am Freitag, 28. September 2007 schrieb Nikolay Samokhvalov:
J=?ISO-8859-1?B?9g==?=rg Beyer [EMAIL PROTECTED] writes:
Attached is the log with the du output, one block for the build directory,
one for the installation directory, and one for the 8.3-cluster. Some
comments are added.
I suspect gprof to be the culprit, everything gprof related is
You see, I'm not a trained developer, I'm just a dumb psychologist,
sometimes poking around w/ things I don't fully understand -- learning by
doing, or die trying ;-) Give me at least three years...
Seriously now, I didn't even think about possible downsides of
--enable-profiling, I just
[EMAIL PROTECTED] writes:
Is there a query I can use to know all the unamed trigger, delete them and
recreate with the right sentence?
I've applied a patch that should persuade the backend to convert the old
CREATE CONSTRAINT TRIGGER commands into proper foreign-key constraints.
I'd suggest
I wrote:
However, accumulation of zillions of gmon.out files is definitely a
downside of the approach; one that I've noticed myself. I've also
noticed that it takes a heck of a long time to rm -rf $PGDATA once
you've built up a few tens of thousands of gprof subdirectories. What's
worse,
23 matches
Mail list logo
