Am Donnerstag, 6. Januar 2005 17:39 schrieb Jim Buttafuoco:
I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25
(with has CONFIG_FPE_NWFPE=y) and ALL tests passed.
OK, that's good enough. At least we found the cause of the problem. Future
generations can look in the
Am Donnerstag, 6. Januar 2005 16:30 schrieb Honda Shigehiro:
2) mkdir?
Due to odd behavior of 'mkdir -p' command, I got below error when 'make
install': mkdir -p -- /usr/local/pgsql/bin /usr/local/pgsql/share
mkdir: cannot create /usr/local/pgsql/share.
/usr/local/pgsql/share: File exists
On Fri, 7 Jan 2005, Bruce Momjian wrote:
Do we want to add this additional log infor to CVS for 8.0?
No, unless we're looking for an RC5?
---
Simon Riggs wrote:
On Mon, 2005-01-03 at 19:14 -0500, Bruce Momjian wrote:
Simon
Michael Glaesemann wrote:
Having the release earlier in the week also means there will probably be
more people online to quickly respond to any issues that arise with the
release. Then again, it also means its more likely more people will be
exposed to any such issues as well. Weighing the two,
Hello,
This installdirs are worked well. 'make install' succeeds without
modifying Makefiles.
Thank you.
regards,
--
Shigehiro Honda
From: Peter Eisentraut [EMAIL PROTECTED]
Subject: Re: [HACKERS] Porting/platforms/buildfarm open issues
Date: Fri, 7 Jan 2005 10:53:56 +0100
Am Donnerstag,
Hello, I'm trying to make an array constructor function
work for PGSQL from 72 to 80.
My current problem is that in PG73 the ArrayType structure
wants an elementtype but FmgrInfo does not contain the Oid
of the given argument (only of the function).
Is there an easy way to either:
-
I'm curious, the original run you posted with 3825 NOTPM is still 17%
faster than the latest pg_autovacuum run which shows 3280 NOTPM. Is
this on the same hardware? Also, did the original non-pg_autovacuum run
any manual vacuum commands? Also, does the non-pg_autovacuum run start
slowing
Am Freitag, 7. Januar 2005 13:10 schrieb Honda Shigehiro:
This installdirs are worked well. 'make install' succeeds without
modifying Makefiles.
Does anyone object to installing the new mkinstalldirs? I took the latest
version from the automake CVS. The important change was apparently to use
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 7 Jan 2005, Bruce Momjian wrote:
Do we want to add this additional log infor to CVS for 8.0?
No, unless we're looking for an RC5?
I vote no as well. While it's probably not a dangerous change, the need
for it has not been demonstrated.
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 6 Jan 2005, Bruce Momjian wrote:
I agree Magnus has a point here. We just did major changes for Win32
configuration file locations and it seems it is a mistake to not have
sufficient time for testing and to see if something else comes up.
Hello
We made Compiere (Open source ERP system) to Firebird (Fyracle)
This is special version of Firebird with added Oracle compatibility (Oracle
PL/SQL).
It made porting much easier, but our experience show that it
would be now also not very difficult with other databases like PostgreSQL.
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Freitag, 7. Januar 2005 17:20 schrieb Tom Lane:
Could you post a diff against what we have now?
Attached.
Looks ok to me.
regards, tom lane
---(end of broadcast)---
TIP 1:
Marek Mosiewicz wrote:
Hello
We made Compiere (Open source ERP system) to Firebird (Fyracle)
This is special version of Firebird with added Oracle compatibility
(Oracle
PL/SQL).
It made porting much easier, but our experience show that it
would be now also not very difficult with other
Ok, but what I'm curious to do is see if you run the non-pg_autovacuum
test for a long time (4 hours? more?) when does it get slower that
running with pg_autovacuum. And, can you demonstrate that running the
tests with pg_autovacuum for a long time (say 4 hours) that the
performance stays
Mark,
No manual vacuum commands before. The decline in performance has been
pretty consistent in all my previous tests and people have told me on
many occasions that the decline in performance was probably because I
was never using vacuum...
Hmmm ... what autovacuum params are you using?
On Fri, Jan 07, 2005 at 09:58:47AM -0800, Josh Berkus wrote:
Mark,
No manual vacuum commands before. The decline in performance has been
pretty consistent in all my previous tests and people have told me on
many occasions that the decline in performance was probably because I
was never
Upps sorry now found it on TODO list.
I was not aware that it is SQL92 standard.
Is it difficult to implement ?
Simplest approach would be
to rewrite it to UPDATE t1 set col1 = (select cola ...), col2 = (select
colb)
but it would result in not optimal plan.
Marek Mosiewicz
Mark,
All default parameters. Matthew also recommended using the
vacuum_delay setting so I was about to try that.
Interesting ... the default parameters are quite conservative, running only
when the table has doubled in new rows. So if those spikes are vacuums,
then the DBT2 test is
Hi there,
I just completed russian translation of .po files ( except
ru.po for backend ).
diff against rc3 is available from
http://www.sai.msu.su/~megera/postgres/docs/ru.po-8.0.0.rc3.diff.gz
Oleg
On Thu, 6 Jan 2005, Serguei Mokhov wrote:
- Original Message -
From: Peter Eisentraut
Marek Mosiewicz wrote:
Upps sorry now found it on TODO list.
I was not aware that it is SQL92 standard.
Is it difficult to implement ?
Simplest approach would be
to rewrite it to UPDATE t1 set col1 = (select cola ...), col2 = (select
colb)
but it would result in not optimal plan.
Doesn't
On Fri, Jan 07, 2005 at 10:13:52AM -0800, Josh Berkus wrote:
Mark,
All default parameters. Matthew also recommended using the
vacuum_delay setting so I was about to try that.
Interesting ... the default parameters are quite conservative, running only
when the table has doubled in new
On Fri, 7 Jan 2005, Merlin Moncure wrote:
Marek Mosiewicz wrote:
Hello
We made Compiere (Open source ERP system) to Firebird (Fyracle)
This is special version of Firebird with added Oracle compatibility
(Oracle
PL/SQL).
It made porting much easier, but our experience show that it
Various recent and not so recent problem reports got me thinking again
that it might be worth switching our shared library build system to
libtool. Among those are:
- Guesswork about which spellings of -rpath, -export-dynamic, -fpic etc.
work on a particular platform or compiler.
- Lack of
Merlin Moncure wrote:
Andreas wrote:
Doesn't something like
UPDATE t1 SET col1=cola, col2=colb
FROM t1 JOIN anothertable ot ON t1.id=ot.id
WHERE ...
Work the way you'd like it? I'd expect this syntax to be as widely
portable and performant.
Hmm, 'from' in an update is a PostgreSQL extension
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 7 Jan 2005, Bruce Momjian wrote:
Do we want to add this additional log infor to CVS for 8.0?
No, unless we're looking for an RC5?
I vote no as well. While it's probably not a dangerous change, the need
for it has not
Mark Wong wrote:
On Fri, Jan 07, 2005 at 10:13:52AM -0800, Josh Berkus wrote:
Mark,
All default parameters. Matthew also recommended using the
vacuum_delay setting so I was about to try that.
Interesting ... the default parameters are quite conservative, running only
when the
On Fri, 7 Jan 2005, Peter Eisentraut wrote:
Various recent and not so recent problem reports got me thinking again
that it might be worth switching our shared library build system to
libtool. Among those are:
- Guesswork about which spellings of -rpath, -export-dynamic, -fpic etc.
work on a
Hi,
If this is not the appropriate list I apologize.
Anyway, I am using Borland Delphi 7 and Zeoslib PG access components and
I have just noticed that when I restore a database from
7.x and then load the function source into my program and make a change,
i.e. compile it, the next time I open it
Hi,
i was looking at the unsuported features in the RC4
docs and found this:
F671| Enhanced integrity management| Subqueries in
CHECK| intentionally omitted
Why is it *intentionally omitted*?
Is it to hard? or has some side-effects?
just a question!
regards,
Jaime Casanova
29 matches
Mail list logo
