People might be more interested in debating this topic with you if we
hadn't discussed it at length just a couple months back. There wasn't
consensus then that we had to offer an escape hatch, and you've not
offered any argument that wasn't made before.
I'm simply presenting a problem for
Late in the 7.4 release we've added a patch that changed -fpic to -fPIC
for Linux Sparc. We wanted to investigate that issue further later on.
I've tried building PostgreSQL with -fpic on Sparc and saw no problems.
So I suggest that we change back to -fpic until we get detailed evidence.
Any
Hi,
in our TODO is the item: Add PL/PgSQL packages.
I thought about it and for example Oracle's CREATE PACKAGE / PACKAGE
BODY seems really interesting and modular. IMHO it's interesting item
in PostgreSQL TODO, but I think there a is small collision between the
schemas and possible
Karel Zak writes:
in our TODO is the item: Add PL/PgSQL packages.
I think the interesting part are the package-global variables. The
name hierarchy seems completely redundant with schemas.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
On Fri, Nov 28, 2003 at 02:35:11PM +0100, Peter Eisentraut wrote:
Karel Zak writes:
in our TODO is the item: Add PL/PgSQL packages.
I think the interesting part are the package-global variables. The
name hierarchy seems completely redundant with schemas.
Agree, but there is more
Oli Sennhauser wrote:
People might be more interested in debating this topic with you if we
hadn't discussed it at length just a couple months back. There wasn't
consensus then that we had to offer an escape hatch, and you've not
offered any argument that wasn't made before.
I'm simply
Karel Zak [EMAIL PROTECTED] writes:
On Thu, Nov 27, 2003 at 09:49:22AM +0100, Nhan NGO DINH wrote:
This output has been obtained from a PostgreSQL 7.3.4
I think it's fixed in 7.4.
Yes. The patch will also be in 7.3.5 when we release that (probably in
the next week or so).
Teodor Sigaev [EMAIL PROTECTED] writes:
Explain analyze takes 3 times more time for execution. Why?
Measurement overhead. It would seem your platform has a particularly
slow version of gettimeofday() though ... I've never noticed such a
large discrepancy myself.
Stephen Frost [EMAIL PROTECTED] writes:
Consider the following input data:
1234,24.50,10-Jan-2003,10/1/03,10-01-2003,hiall
The interpretation for the numbers is:
1234 =3D 12.34, 24.50 =3D 24.50
The interpretation for the dates is:
January 10th, 2003, October 1st, 2003, October
E.Rodichev [EMAIL PROTECTED] writes:
/e:2createdb test
test | er | SQL_ASCII - Incorrect!
(3 rows)
Let's note than the last line is in fact completely incorrect.
What's incorrect about it? You didn't ask for any other encoding
than SQL_ASCII.
You can set the default
On Fri, 28 Nov 2003, Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
Explain analyze takes 3 times more time for execution. Why?
Measurement overhead. It would seem your platform has a particularly
slow version of gettimeofday() though ... I've never noticed such a
large
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Consider the following input data:
1234,24.50,10-Jan-2003,10/1/03,10-01-2003,hiall
The interpretation for the numbers is:
1234 =3D 12.34, 24.50 =3D 24.50
The interpretation for the dates is:
Marc G. Fournier [EMAIL PROTECTED] writes:
Actually, I'm noticing similar problems with v7.4 ... EXPLAIN ANALYZE
seems to be showing some *very* high ms for execution time, but if you run
the actual query, it doesn't seem to take even 1/10th the time reported
...
Example? I don't see
Stephen Frost [EMAIL PROTECTED] writes:
I guess my example was lacking, I'm sure there are cases where the
text-date casting will end up being wrong or some date style won't be
accepted. If the above was 'January 10th, 2003, October 1st, 2003,
January 1st, 2003', for example. Thinking back I
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I guess my example was lacking, I'm sure there are cases where the
text-date casting will end up being wrong or some date style won't be
accepted. If the above was 'January 10th, 2003, October 1st, 2003,
Peter Eisentraut [EMAIL PROTECTED] writes:
I've tried building PostgreSQL with -fpic on Sparc and saw no problems.
So I suggest that we change back to -fpic until we get detailed evidence.
Okay with me. It never struck me that we'd really seen adequate
evidence that -fPIC was needed.
Stephen Frost [EMAIL PROTECTED] writes:
No, I'm interested, as I discussed in my message[1], in the ability to
use functions in a copy statement to allow me to specify the conversion
from text to the appropriate data type.
COPY is not intended to be that flexible; it's intended to be fast.
You
On Fri, 28 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Actually, I'm noticing similar problems with v7.4 ... EXPLAIN ANALYZE
seems to be showing some *very* high ms for execution time, but if you run
the actual query, it doesn't seem to take even 1/10th the time
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
No, I'm interested, as I discussed in my message[1], in the ability to
use functions in a copy statement to allow me to specify the conversion
from text to the appropriate data type.
COPY is not intended to be
How many times is gettimeofday called?
wow=# explain analyze select 1;
QUERY PLAN
Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.008..0.010 rows=1 loops=1)
Total
Teodor Sigaev [EMAIL PROTECTED] writes:
How many times is gettimeofday called?
Twice per plan node visit, if you are doing EXPLAIN ANALYZE. (The
number of visits is one more than the number of rows returned.)
regards, tom lane
---(end of
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
You can do any amount of processing you want in an INSERT statement,
though.
Certainly, but for bulk loads that requires more pre-processing work for
the user and I believe results in more work for the server too
... if its just me mis-reading the numbers, let me
know ... it just feels off
Here's what I see:
time psql -c explain analyze SELECT count(rec_id) FROM url 186_archives
QUERY PLAN
Peter Eisentraut wrote:
Hans-Jürgen Schönig writes:
Especially the disaster recovery mechanism and things such as adding new
masters need some more work.
Yes, someone is working on automatic recovery (which would extend to
adding new masters by starting recovery from zero). In fact, they're
I really like the idea of taking a snapshot backup with postgres, using
either volume manager or hardware splits in a disk array to get a
physical backup.
In other, lesser database systems :) the system is structured to prevent
problems arising from split block writes, meaning that though the
Dave,
I know that the backend does - it is an essential feature.
Clustered JDBC parses the statement sent to it in order to find out what
to do with it. I have played around a little (mostly interactive shell).
You will find out that Clustered JDBC will complain in this case because
it doesn't
Just a thought. You could also run the regression test automatically after a
successful build?
Andrew Dunstan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Jean-Michel POURE wrote:
Le Vendredi 21 Novembre 2003 19:47, Tom Lane a écrit :
I think the main value of a build farm
Andreas Pflug kirjutas N, 20.11.2003 kell 16:10:
Hannu Krosing wrote:
You are just shifting the interface problems to a place needing way more
changes in the backend. There will be some problems either way.
Not quite. Certainly, basing internal storage on attstoragenum is more
We had this discussion. information_schema doesn't deliver enough info
needed for admin tools.
It should. This is the sole reason for existance of it. If it is not
enough, then it should be updated.
It can't. ANSI says only objects owned by the user are shown. Admins
might be quite
[EMAIL PROTECTED] (Christopher Kings-Lynne) wrote in message news:[EMAIL
PROTECTED]...
Lastly, I presume it's possible to create a system of circular
dependencies (eg create or replace view), which really cannot be solved
without a system of 'shells', similar to that needed to dump types and
Here's a slightly condensed version - do SQL functions have an advantage in
that they can be inlined? Or have I misunderstood?
CREATE OR REPLACE FUNCTION user_in_group(name,name) RETURNS boolean STRICT
AS '
SELECT EXISTS(SELECT u.* FROM pg_catalog.pg_user u INNER JOIN
pg_catalog.pg_group g ON
We're looking at storing the equivalent of very large rasters images
in
postgres. Our understanding is that postgres stores large objects
as little pieces in rows of a table. As our images would be 30MB-4GB
in size, this would be a lot of rows. Has anybody used a different
mechanism to store their
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 26 November 2003 09:19, Hannu Krosing wrote:
First, You could start by implementing materialized views manually,
using tables and triggers, to get the feel of what should be generated.
Next, still working from frontend, try to make
Title: Message
Hi
We are attempting to
setup a database application on a Linuxbox, but we are
having
problems loading
data with particular dates.
My colleague, Arnold
Mavromatis has already made postings to the pgsql-bugs list,
but we are still no
closer to having the bug fixed, so I
They stopped at 7.2.4 because they're finishing some usefull APIs,
which'll make the port much more easy.
Will this involve using a Linux kernel ;)
:) No, a NW kernel with a POSIX library. This'll be great, because
:you'll can run powerfull opensource software with an enterprise-class
Today I've d-loaded PostgreSQL 7.3.4.
I've seen in
$PGSQLD/doc/html/index.html
it still says
Copyright (C) 1996-2002
shouldn't it be 2003?
We only update the copyright notices when we are preparing a major
release. (Bruce just did it a week or two back for 7.4, for example.)
Updating
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
Recently I have come across a simple issue which made me think about it.
When we create a tmp table (SELECT INTO, CREATE TABLE AS) the planner
won't know anything about its content after creating it.
Run ANALYZE
I get the feeling that what we will see is the destination
filename already present and the source not, which would suggest
that two backends tried to do the rename concurrently.
Tom,
I just noticed that the rename panic errors like this one:
PANIC: rename from
Since upgrading to 7.3 I've noticed that the ORDER BY clause seems to
ignore leading spaces/punctuation for eg we have a simple table with 6
rows containing:
'a'
'b'
'c'
'd'
' bill'
'-bill'
SELECT * FROM table ORDER BY 1;
gives:
a
b
bill
-bill
c
d
which is different from previous versions
Looks good. Once you are comfortable with the changes, you will need to
add another line to CVSROOT/options to disable processing of the $Id$
and $Header$ tags should one accidentally be added.
tagexpand=iPostgreSQL
'K, where do you find docs on the options file? there is
On Fri, 28 Nov 2003, Rod Taylor wrote:
k, there was no options file already, so I just added it containing the
one line ...
And tested in on GNUMakefile.in, and appears okay:
#
# $PostgreSQL: pgsql-server/GNUmakefile.in,v 1.36 2003/11/28 20:32:09 pgsql Exp $
#
Looks good. Once
k, there was no options file already, so I just added it containing the
one line ...
And tested in on GNUMakefile.in, and appears okay:
#
# $PostgreSQL: pgsql-server/GNUmakefile.in,v 1.36 2003/11/28 20:32:09 pgsql Exp $
#
Looks good. Once you are comfortable with the changes, you will
None that I've heard of ... Sean?
Tom, any way of writing a quite test C program for this? Something to
'simulate' the same thing, but without having to build the whole
postmaster?
On Fri, 28 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Tom Lane
I said:
I'm wondering if there's an actual bug in gettimeofday() in this
platform, such that once in a while it returns a value that's off
a minute or so ...
Whoa. Try the following test program. Then send it in to your friendly
local BSD hackers
uname -a
FreeBSD pgsql74.hub.org
On Thu, 27 Nov 2003, Rod Taylor wrote:
On Thu, 2003-11-27 at 00:50, Marc G. Fournier wrote:
Based on discussions on -hackers, and baring any objections betwen now and
then, I'm going to go through all files in CVS and change:
$Id$ - $PostgreSQL$
I will do this the evening of
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Tom Lane wrote:
Now that I recall, didn't you complain of something similar with a beta?
Yup ... and I bet its not reproducible yet again, is it? :) That would
make for twice though, with v7.4, that I've come up with - results
Teodor Sigaev [EMAIL PROTECTED] writes:
Tom, I am afraid that I don't understand. My first example:
wow=# explain analyze select max(click.accesses) from click;
QUERY PLAN
On Fri, 28 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
did you happen to take a look at the other set of queries I sent you, that
were showing 39k and 41k explain results?
You mean this one?
Yup ...
time psql -c explain analyze select max(intag) from ndict3
Tom, I am afraid that I don't understand. My first example:
wow=# explain analyze select max(click.accesses) from click;
QUERY PLAN
-
Marc G. Fournier [EMAIL PROTECTED] writes:
did you happen to take a look at the other set of queries I sent you, that
were showing 39k and 41k explain results?
You mean this one?
time psql -c explain analyze select max(intag) from ndict3 186_archives
Paul Tuckfield wrote:
I really like the idea of taking a snapshot backup with postgres, using
either volume manager or hardware splits in a disk array to get a
physical backup.
In other, lesser database systems :) the system is structured to prevent
problems arising from split block writes,
did you happen to take a look at the other set of queries I sent you, that
were showing 39k and 41k explain results? do they show pretty much the
same 'lag' in gettimeofday()?
On Fri, 28 Nov 2003, Tom Lane wrote:
... if its just me mis-reading the numbers, let me
know ... it just feels off
Ollie Clark writes:
Since upgrading to 7.3 I've noticed that the ORDER BY clause seems to
ignore leading spaces/punctuation for eg we have a simple table with 6
rows containing:
You need to set the right locale. You appear to expect the C locale, so
you need to tell initdb about it.
--
On Wed, Nov 26, 2003 at 05:34:28PM +0100, Hans-Jürgen Schönig wrote:
The reason why I came up with this posting is slightly different: Assume
a JDBC application which works with PostgreSQL + some other database. If
you want to use both databases without PostgreSQL being unnecessarily
slow
On Thu, 27 Nov 2003, Mike Macaskill wrote:
Linux 2.4.20, PG 7.3.2 (this is the box where we wish to run our
application)
HP-UX 11.11, PG 7.3.2, 7.3.4, 7.4 (this is just a test box where PG
installs take less time)
On all of these configurations the the date '1901/12/14' apparently does not
On Wed, 25 Nov 2003, Paul Tuckfield wrote:
I really like the idea of taking a snapshot backup with postgres, using
either volume manager or hardware splits in a disk array to get a
physical backup.
Does anyone else see any value in snapshotting. It would, I image,
essentially work like this:
Gavin Sherry [EMAIL PROTECTED] writes:
What to do? Well, as far as I can tell, there are no work arounds
This was discussed a few months ago and set aside because no one had a
really decent solution at the time.
The behavior is not really all that different from the discontinuities
that occur
On November 28, 2003 12:33 pm, Tom Lane wrote:
I said:
I'm wondering if there's an actual bug in gettimeofday() in this
platform, such that once in a while it returns a value that's off
a minute or so ...
Whoa. Try the following test program. Then send it in to your friendly
local BSD
Darcy Buskermolen [EMAIL PROTECTED] writes:
On November 28, 2003 12:33 pm, Tom Lane wrote:
Whoa. Try the following test program. Then send it in to your friendly
local BSD hackers
I've been running this code on a pair of FreeBSD (i386) boxen, for some time
now, one of which is a
I said:
The failure is definitely quite repeatable on pgsql74.hub.org. I don't
see it on svr1.postgresql.org, though, which seems to be running almost
the same kernel.
After looking more closely, I take that back: svr1 is failing too,
though not as often:
uname -a
FreeBSD
On November 28, 2003 12:33 pm, Tom Lane wrote:
I said:
I'm wondering if there's an actual bug in gettimeofday() in this
platform, such that once in a while it returns a value that's off
a minute or so ...
Whoa. Try the following test program. Then send it in to your friendly
local BSD
On Fri, 28 Nov 2003, Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
On November 28, 2003 12:33 pm, Tom Lane wrote:
Whoa. Try the following test program. Then send it in to your friendly
local BSD hackers
I've been running this code on a pair of FreeBSD (i386) boxen,
On November 28, 2003 04:19 pm, Tom Lane wrote:
I said:
The failure is definitely quite repeatable on pgsql74.hub.org. I don't
see it on svr1.postgresql.org, though, which seems to be running almost
the same kernel.
After looking more closely, I take that back: svr1 is failing too,
Nigel J. Andrews [EMAIL PROTECTED] writes:
On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45, but they
are all just a microsecond.
What do you mean by just a microsecond?
Attached is a tightened-up test program that will only complain if the
value of gettimeofday goes backward (at
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45, but they
are all just a microsecond.
What do you mean by just a microsecond?
I mean it's always a out of order tv_usec... line and the difference
Darcy Buskermolen [EMAIL PROTECTED] writes:
After 30+ minutes I'm now starting to see the same problems on my 5.2 testbed
as well. I'm going to fire this test up on my FreeBSD 3.x and 2.x boxen and
see if' it's there too. I can confirm that this not a SMP issue as that it's
happeing on both
Nigel J. Andrews [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45, but they
are all just a microsecond.
What do you mean by just a microsecond?
I mean it's always a out of
Tom Lane [EMAIL PROTECTED] writes:
Whoa. Try the following test program.
I tried this on two uniprocessor x86 machines:
(1)
$ uname -a
Linux tokyo 2.6.0-test10 #3 Mon Nov 24 13:43:54 EST 2003 i686 GNU/Linux
This machine produces this output, after running the test app for
about 30 minutes:
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
On an Intel Linux 2.4.18 I get them quite often, 25 in 1'45, but they
are all just a microsecond.
What do you mean by just
On Fri, 28 Nov 2003, Darcy Buskermolen wrote:
I've been running this code on a pair of FreeBSD (i386) boxen, for some time
now, one of which is a 4.8-STABLE, the other is a 5.2-BETA.
In 10 minutes of execution the 4.8 box has only shown the following:
out of order tv_sec: 1070063393 115226,
Nigel J. Andrews [EMAIL PROTECTED] writes:
Ah, I have made a mistake. It's only a 2.2.18 kernal. Dual SMP P-III, perhaps
that's the issue there.
Hm. I seem to recall there were still lots of SMP bugs in the 2.2.*
kernels.
And on the FreeBSD system I've got this:
$ time ./a.out 21 | tee
On Fri, 28 Nov 2003, Tom Lane wrote:
Could it be a hardware problem on Marc's box? Or specific to some other
aspect of that installation (Marc, is pgsql74.hub.org multi-CPU, for
example?)
All the servers are SMP ... pgsql74 is on a Dual-Xeon ...
Marc G. Fournier Hub.Org
Marc G. Fournier [EMAIL PROTECTED] writes:
I'm suspecting that the issue is amplified by load on the server itself
That would fit right in with my idea that the failure occurs when the
process loses its timeslice partway through gettimeofday(). Heavier
load would presumably make it more likely
On Fri, 28 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I'm suspecting that the issue is amplified by load on the server itself
That would fit right in with my idea that the failure occurs when the
process loses its timeslice partway through gettimeofday(). Heavier
On Fri, 28 Nov 2003, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
$ time ./a.out 21 | tee a.txt
out of order tv_sec: 1070066197 273140, prev 1070066195 721010
out of order tv_usec: 1070066197 273140, prev 1070066195 721010
out of order tv_sec: 1070067322 116061, prev
Marc G. Fournier [EMAIL PROTECTED] writes:
Just got my first response on this, and, in fact, this is 'acceptable
behaviour' to a certain extent ... there is a kernel tuneable called
kern.timecounter.method, that is either 1 or 0:
15 minutes of error is acceptable?
On Fri, 28 Nov 2003, Marc G. Fournier wrote:
On Fri, 28 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I'm suspecting that the issue is amplified by load on the server itself
That would fit right in with my idea that the failure occurs when the
process loses its
As of this change:
http://archives.postgresql.org/pgsql-committers/2003-11/msg00278.php
I can't seem to configure --with-krb5.
The configure script I've used (derived from what the the RH9 RPM spec
file does) for quite some time now is:
./configure \
--host=i386-redhat-linux \
On Fri, 28 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Just got my first response on this, and, in fact, this is 'acceptable
behaviour' to a certain extent ... there is a kernel tuneable called
kern.timecounter.method, that is either 1 or 0:
15 minutes of error
Marc G. Fournier [EMAIL PROTECTED] writes:
15 minutes of error is acceptable?
Apparently *shrug* That was just the first answer back though, so we'll
see what happens ...
BTW, it seems from this thread that the BIND guys have seen even more
bogus behavior than this from gettimeofday() on
Joe Conway [EMAIL PROTECTED] writes:
As of this change:
http://archives.postgresql.org/pgsql-committers/2003-11/msg00278.php
I can't seem to configure --with-krb5.
I believe the idea is that instead of
--with-krb5=/usr/kerberos
you now need
--with-krb5
On Fri, 28 Nov 2003, Neil Conway wrote:
$ uname -a
FreeBSD home.samurai.com 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Thu Nov 6 21:25:41 EST
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAMURAI i386
This machine produces no output after running the test app for about
30 minutes.
what is
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
As of this change:
http://archives.postgresql.org/pgsql-committers/2003-11/msg00278.php
I can't seem to configure --with-krb5.
I believe the idea is that instead of
--with-krb5=/usr/kerberos
you now need
--with-krb5
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Neil Conway wrote:
$ uname -a
FreeBSD home.samurai.com 4.9-RELEASE [...]
what is kern.timecounter.method set to?
$ sysctl kern.timecounter.method
kern.timecounter.method: 0
FYI, I ran the test program for another 30 minutes
On Fri, 28 Nov 2003, Neil Conway wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 28 Nov 2003, Neil Conway wrote:
$ uname -a
FreeBSD home.samurai.com 4.9-RELEASE [...]
what is kern.timecounter.method set to?
$ sysctl kern.timecounter.method
kern.timecounter.method: 0
FYI,
Marc G. Fournier [EMAIL PROTECTED] writes:
What kinda processor are you running?
From dmesg:
Timecounter i8254 frequency 1193182 Hz
CPU: Intel Celeron (631.29-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
On Fri, 21 Nov 2003, Matthew T. O'Connor wrote:
Do you know of an easy way to get a
count of the total pages used by a whole cluster?
Select sum(relpages) from pg_class.
You might want to exclude indexes from this calculation. Some large
read only tables might have indexes larger than the
87 matches
Mail list logo
