./configure --without-readline
Everything compiled fine, and all tests passed on make check.
However, when I looked at my server this morning, one of the four
postmaster process was taking all CPU on one of my core (no db was
created, the postmaster should have been totally idle)
load
Hello, I'm using PostgreSQL 8.0.4 in Fedora Core 3, right now I'm learning a
little about the postgresql internals and the way some kind of SPs could be
written in c language; I found something really weird and I cannot explain
to me this behavior:
#include postgres.h
#include fmgr.h
The 8.1 supported-platforms list is looking pretty good, I think -- we
don't have updates for every single combination of OS and hardware,
but we have updates for every OS and at least one instance of all
supported CPU types.
Except IRIX. There's been no port report since Robert Bruccoleri
Cedric Berger wrote:
I tried to stop postgress using: 'su - postgres -c pg_ctl stop -swm
fast'
but that function never returns. Even kill -9 couldn't stop the process.
This looks like a Solaris bug firstly, but I thought I'd mention it.
Yeah, that sounds like it's stuck in the kernel.
Classic behaviour, which has nothing to do with postgres. Try the
program below to see the same effect. You probably should be using a
rounding function to see what you seem to expect.
cheers
andrew
#include stdio.h
main()
{
double x[] = { 0.1, 0.11, 0.12, 0.13, 0.14, 0.15 };
int i,n;
On Fri, Nov 04, 2005 at 10:16:50AM -0600, Cristian Prieto wrote:
Hello, I'm using PostgreSQL 8.0.4 in Fedora Core 3, right now I'm learning a
little about the postgresql internals and the way some kind of SPs could be
written in c language; I found something really weird and I cannot explain
Cristian Prieto [EMAIL PROTECTED] writes:
Datum
repeat_item(PG_FUNCTION_ARGS)
{
int num_times;
num_times = PG_GETARG_FLOAT8(0) * 100;
PG_RETURN_INT32(num_times);
}
# Create or replace function test(float) returns integer as 'test.so'
language 'c' stable;
float
On Thu, Nov 03, 2005 at 09:17:43PM -0500, Tom Lane wrote:
Gregory Maxwell [EMAIL PROTECTED] writes:
Another way to look at this is in the context of compression: With
unicode, characters are really 32bit values... But only a small range
of these values is common. So we store and work with
[snip]
Floating points numbers are accurate but not precise.
OK, now this one beats me... what's the difference between accurate
and exact ? I thought both mean something like correct, but precise
refers to some action and accurate applies to a situation or
description...
I'm actually curios
Csaba Nagy wrote:
[snip]
Floating points numbers are accurate but not precise.
OK, now this one beats me... what's the difference between accurate
and exact ? I thought both mean something like correct, but
precise refers to some action and accurate applies to a situation or
I don't know if this fills in any of the gaps, but...
We passed regression tests with 8.1RC1 on dual hyperthreaded
Xeon systems. One had SUSE 9.3 Professional; the other had
Windows Server 2003 Enterprise Edition (Service Pack 1).
Both had 8 GB RAM and six disk drives set up as RAID 5.
I really haven't read up much on the constraint exclusion feature, but
this description in guc.c really doesn't want to make me use it. :)
This prevents table access if the table constraints guarantee that
table access is necessary.
This is a typo, right?
--
Peter Eisentraut
I think the crucial point is that the common IEEE floating point
formats are unable to store an EXACT representation of common
decimal fractions (such as .1) -- they can only store an
APPROXIMATION.
Peter Eisentraut [EMAIL PROTECTED]
Csaba Nagy wrote:
[snip]
Floating points numbers are
On Fri, Nov 04, 2005 at 18:30:56 +0100,
Csaba Nagy [EMAIL PROTECTED] wrote:
[snip]
Floating points numbers are accurate but not precise.
OK, now this one beats me... what's the difference between accurate
and exact ? I thought both mean something like correct, but precise
refers to some
Merlin Moncure [EMAIL PROTECTED] writes:
Nailed it.
problem is in mainloop.c - setup_cancel_handler. Apparently you can
have multiple handlers and windows keeps track of them all, even if they
do the same thing. Keeping track of so many system handles would
naturally slow the whole process
[EMAIL PROTECTED] (Tom Lane) writes:
The 8.1 supported-platforms list is looking pretty good, I think -- we
don't have updates for every single combination of OS and hardware,
but we have updates for every OS and at least one instance of all
supported CPU types.
Not to pester overly...
AIX
Merlin Moncure [EMAIL PROTECTED] writes:
Nailed it.
problem is in mainloop.c - setup_cancel_handler. Apparently you
can
have multiple handlers and windows keeps track of them all, even if
they
do the same thing. Keeping track of so many system handles would
naturally slow the whole
On Fri, Nov 04, 2005 at 01:01:20PM -0500, Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
Nailed it.
problem is in mainloop.c - setup_cancel_handler. Apparently you
can have multiple handlers and windows keeps track of them all,
even if they do the same thing. Keeping track
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
Nailed it.
problem is in mainloop.c - setup_cancel_handler. Apparently you can
have multiple handlers and windows keeps track of them all, even if they
do the same thing. Keeping track of so many system handles would
naturally
Merlin Moncure [EMAIL PROTECTED] writes:
AFAICS it is appropriate to move the sigsetjmp and
setup_cancel_handler
calls in front of the per-line loop inside MainLoop --- can anyone see
a reason not to?
hm. mainloop is re-entrant, right? That means each \i would reset the
handler...what is
David Fetter [EMAIL PROTECTED] writes:
On Fri, Nov 04, 2005 at 01:01:20PM -0500, Tom Lane wrote:
I'm inclined to treat this as an outright bug, not just a minor
performance issue, because it implies that a sufficiently long psql
script would probably crash a Windows machine.
Ouch. In light
David Fetter wrote:
On Fri, Nov 04, 2005 at 01:01:20PM -0500, Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
Nailed it.
problem is in mainloop.c - setup_cancel_handler. Apparently you
can have multiple handlers and windows keeps track of them all,
even if they do the
I'm inclined to treat this as an outright bug, not just a minor
certainly...
performance issue, because it implies that a sufficiently long psql
script would probably crash a Windows machine.
actually, it's worse than that, it's more of a dos on the
whole system, as windows will
Peter Eisentraut [EMAIL PROTECTED] writes:
I really haven't read up much on the constraint exclusion feature, but
this description in guc.c really doesn't want to make me use it. :)
This prevents table access if the table constraints guarantee that
table access is necessary.
This is a
On Fri, Nov 04, 2005 at 08:38:38AM -0500, [EMAIL PROTECTED] wrote:
On Thu, Nov 03, 2005 at 09:17:43PM -0500, Tom Lane wrote:
Actually, the real reason we use UTF-8 and not any of the
sorta-fixed-size representations of Unicode is that the backend is by
and large an ASCII,
void
setup_cancel_handler(void)
{
+ static bool done = false;
+
+ if (!done)
SetConsoleCtrlHandler(consoleHandler, TRUE);
+ done = true;
}
That works, I tried ctrl-c various ways including from within \i copy.
Problem solved!
Merlin
On Fri, Nov 04, 2005 at 04:13:29PM +0100, Martijn van Oosterhout wrote:
On Fri, Nov 04, 2005 at 08:38:38AM -0500, [EMAIL PROTECTED] wrote:
On Thu, Nov 03, 2005 at 09:17:43PM -0500, Tom Lane wrote:
Actually, the real reason we use UTF-8 and not any of the
sorta-fixed-size representations
Merlin Moncure [EMAIL PROTECTED] writes:
That works, I tried ctrl-c various ways including from within \i copy.
Problem solved!
Good. I've applied the patch in both HEAD and 8.0 branches.
Since we're very nearly ready to wrap 8.1, would someone with access to
a Windows machine please
AFAICS it is appropriate to move the sigsetjmp and
setup_cancel_handler calls in front of the per-line loop inside
MainLoop --- can anyone see a reason not to?
hm. mainloop is re-entrant, right? That means each \i
would reset the
handler...what is downside to keeping global flag?
[EMAIL PROTECTED] writes:
I read the backend is by and large an ASCII, null-terminated-string
engine with we use UTF-8 [for varlena strings?] as, a lot of the
code assumes varlena strings are '\0' terminated, and an assumption
on my part, that the varlena strings are not stored in the backend
On Fri, Nov 04, 2005 at 01:54:04PM -0500, Tom Lane wrote:
[EMAIL PROTECTED] writes:
I read the backend is by and large an ASCII, null-terminated-string
engine with we use UTF-8 [for varlena strings?] as, a lot of the
code assumes varlena strings are '\0' terminated, and an assumption
on
Lets start with an agreed upon expert, Knuth.
The art of computer programming. Vol2,Seminumerical Algorithms.Ed2.
pg682: Precision: The number of digits in a representation.
pg212: Section: Accuracy of floating point numbers.
A rough (but reasonably useful) way to express the behavior of
floating
My client (same one with the slru.c issue) has had 3 of these in the
past day...
The backtrace:
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0x003b8946fb20 in strlen () from /lib64/tls/libc.so.6
#1 0x003b894428dc in vfprintf () from /lib64/tls/libc.so.6
#2
Cristian,
I bet it's related to some rounding issue and the fact that floating
formats are approximative even for small integers.
Probably 12 ands up being slightly less in floating format (something
like 11.999...), and the cast to integer is truncating it.
Not 100% sure though... read up on
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Magnus Hagander
Sent: Friday, November 04, 2005 10:31 AM
To: Tom Lane; Merlin Moncure
Cc: pgsql-hackers@postgresql.org; pgsql-performance@postgresql.org
Subject: Re: [HACKERS] [PERFORM]
What's happening here is that the multiplication, being
floating point,
has some accumulated error such that when you multiply it by 100 and
convert it to an int, it hits the cutoff.
Trivia...
I heard a story many years ago that landed a programmer in prison...
He worked on the program that
On 11/4/05, Martijn van Oosterhout kleptog@svana.org wrote:
Yeah, and while one way of removing that dependance is to use ICU, that
library wants everything in UTF-16. So we replace copying to add NULL
to string with converting UTF-8 to UTF-16 on each call. Ugh! The
argument for UTF-16 is that
Jim C. Nasby [EMAIL PROTECTED] writes:
The backtrace:
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0x003b8946fb20 in strlen () from /lib64/tls/libc.so.6
#1 0x003b894428dc in vfprintf () from /lib64/tls/libc.so.6
#2 0x003b89461ba4 in vsnprintf () from
On 11/4/05, Tom Lane [EMAIL PROTECTED] wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Yeah, and while one way of removing that dependance is to use ICU, that
library wants everything in UTF-16.
Really? Can't it do UCS4 (UTF-32)? There's a nontrivial population
of our users that
Otto Hirr [EMAIL PROTECTED] writes:
Most notably, the IEEE rep, either single or double, most certainly
has the ability to store the EXACT value for 0.1.
Oh really?
regards, tom lane
---(end of broadcast)---
TIP 5: don't
Martijn van Oosterhout kleptog@svana.org writes:
Yeah, and while one way of removing that dependance is to use ICU, that
library wants everything in UTF-16.
Really? Can't it do UCS4 (UTF-32)? There's a nontrivial population
of our users that isn't satisfied with UTF-16 anyway, so if that
No, the IEEE formats can not store .1 exactly. How close it
comes depends on the rest of the number. For single and
double precision, respectively, the IEEE representations fall
at about:
0.10001490116119384765625
0.155511151231257827021181583404541015625
Libraries must do
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
That works, I tried ctrl-c various ways including from within \i copy.
Problem solved!
Good. I've applied the patch in both HEAD and 8.0 branches.
Since we're very nearly ready to wrap 8.1, would someone with access to
a
On Fri, Nov 04, 2005 at 02:45:41PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
The backtrace:
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0x003b8946fb20 in strlen () from /lib64/tls/libc.so.6
#1 0x003b894428dc in vfprintf () from
On 10/13/05, Josh Berkus josh@agliodbs.com wrote:
Tom,
I think my preference is to allow '24:00:00' (but not anything larger)
as a valid input value of the time datatypes. This for two reasons:
* existing dump files may contain such values
* it's consistent with allowing,
On Thu, Nov 03, 2005 at 04:07:41PM +0100, Marcus Engene wrote:
Simon Riggs wrote:
On Thu, 2005-11-03 at 11:13 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On PostgreSQL, CHAR(12) is a bpchar datatype with all instantiations of
that datatype having a 4 byte varlena header. In this
On Wed, Nov 02, 2005 at 06:45:21PM -0500, Tom Lane wrote:
Robert Creager [EMAIL PROTECTED] writes:
Ran with both for an hour with no problem, where I could produce the ASSERT
failure within minutes for the non patched version.
Great. I'll go ahead and commit the smaller fix into HEAD and
On Thu, Nov 03, 2005 at 10:32:03AM -0500, Tom Lane wrote:
I'd feel a lot happier about this if we could keep the dynamic range
up to, say, 10^512 so that it's still true that NUMERIC can be a
universal parse-time representation. That would also make it even
more unlikely that anyone would
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Nov 03, 2005 at 10:32:03AM -0500, Tom Lane wrote:
I'd feel a lot happier about this if we could keep the dynamic range
up to, say, 10^512 so that it's still true that NUMERIC can be a
universal parse-time representation. That would also make it
Jim C. Nasby [EMAIL PROTECTED] writes:
Could something like that be added to regression, or maybe as a seperate
test case for the buildfarm?
If you don't have a self-contained, reproducible test case, it's a bit
pointless to suggest adding the nonexistent test case to the regression
suite.
On Thu, Nov 03, 2005 at 07:40:15PM -, Andrew - Supernews wrote:
On 2005-11-03, Peter Eisentraut [EMAIL PROTECTED] wrote:
Peter Eisentraut wrote:
Someone wanted to rename a database while someone else was running a
rather long pg_dump, so the rename had to wait, and everyone else had
On Fri, Nov 04, 2005 at 04:30:27PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Nov 03, 2005 at 10:32:03AM -0500, Tom Lane wrote:
I'd feel a lot happier about this if we could keep the dynamic range
up to, say, 10^512 so that it's still true that NUMERIC can be a
On Fri, Nov 04, 2005 at 04:35:10PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Could something like that be added to regression, or maybe as a seperate
test case for the buildfarm?
If you don't have a self-contained, reproducible test case, it's a bit
pointless to
On Fri, Nov 04, 2005 at 04:34:35PM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
On Fri, Nov 04, 2005 at 02:45:41PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
The backtrace:
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0
Chris Browne wrote:
[EMAIL PROTECTED] (Tom Lane) writes:
The 8.1 supported-platforms list is looking pretty good, I think -- we
don't have updates for every single combination of OS and hardware,
but we have updates for every OS and at least one instance of all
supported CPU types.
Not
Jim C. Nasby wrote:
On Fri, Nov 04, 2005 at 04:35:10PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Could something like that be added to regression, or maybe as a seperate
test case for the buildfarm?
If you don't have a self-contained, reproducible test
On Fri, Nov 04, 2005 at 05:26:25PM -0500, Andrew Dunstan wrote:
Well, for things like race conditions I don't know that you can create
reproducable test cases. My point was that this bug was exposed by
databases with workloads that involved very high transaction rates. I
know in the case of my
Hi,
I have been playing around with pg_reload_conf() and the pg_settings view.
I understand that the pg_settings view, if updated, applies to the
current session only.
However I was under the impression that if I did a pg_reload_conf(), the
pg_settings view would be updated at that time, but
On Fri, Nov 04, 2005 at 02:58:05PM -0500, Gregory Maxwell wrote:
The correct question to ask is something like Does it support non-bmp
characters? or Does it really support UTF-16 or just UCS2?
UTF-16 is (now) a variable width encoding which is a strict superset
of UCS2 which allows the
Robert Creager [EMAIL PROTECTED] writes:
I have a Perl script, a Perl module and a 1Mb database (from pg_dump
-F c). Are you interested at this time in receiving this?
Sure. Please send it off-list, of course.
An upgrade to RC2 might occur when RC2 comes out, unless there would
be great
On Thu, 03 Nov 2005 18:29:09 +
Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2005-11-03 at 08:03 -0800, Mark Wong wrote:
On Tue, 01 Nov 2005 07:32:32 +
Simon Riggs [EMAIL PROTECTED] wrote:
Concerned about the awful checkpointing. Can you bump wal_buffers to
8192 just to make
On 11/4/05, Martijn van Oosterhout kleptog@svana.org wrote:
[snip]
: ICU does not use UCS-2. UCS-2 is a subset of UTF-16. UCS-2 does not
: support surrogates, and UTF-16 does support surrogates. This means
: that UCS-2 only supports UTF-16's Base Multilingual Plane (BMP). The
: notion of UCS-2
Tony Caduto [EMAIL PROTECTED] writes:
However I was under the impression that if I did a pg_reload_conf(), the
pg_settings view would be updated at that time, but that does not seem to
happen.
It works for me ...
regression=# select setting from pg_settings where name =
On Fri, 4 Nov 2005, Jim C. Nasby wrote:
On Fri, Nov 04, 2005 at 05:26:25PM -0500, Andrew Dunstan wrote:
Well, for things like race conditions I don't know that you can create
reproducable test cases. My point was that this bug was exposed by
databases with workloads that involved very high
Jim C. Nasby [EMAIL PROTECTED] writes:
My client (same one with the slru.c issue) has had 3 of these in the
past day...
(gdb) print *str
$39 = {data = 0x848030 2005-11-04 00:01:02 EST|2005-11-04 00:00:08
EST|216.187.113.78(39476)|didit|, len = 76,
maxlen = 256, cursor = 0}
Um, what's
Tom Lane [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Tony Caduto [EMAIL PROTECTED] writes:
However I was under the impression that if I did a pg_reload_conf(), the
pg_settings view would be updated at that time, but that does not seem to
happen.
I repeated Tony's result
Qingqing Zhou wrote:
test=# LOG: received SIGHUP, reloading configuration files
test=# select setting from pg_settings where name = 'constraint_exclusion';
setting
-
off
(1 row)
test=# select setting from pg_settings where name = 'constraint_exclusion';
setting
-
on
(1
What's the delay? 1s? 5? 10?
Delay is the time difference we kill a signal and the time we really
process it. We kill at once, but only process it at proper idle time. In
my test, the delay is 2 seconds or so. I am looking into the problem - not
sure the exact details now though ...
On Thu, 20 Oct 2005 17:35:31 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Robert Creager [EMAIL PROTECTED] writes:
Interesting. 7.4.1 is worse for this test, as two jump up to 130k. But, my
app runs fine against 7.4.1...
Would it still be helpful to try and pull together a test case from my
Qingqing Zhou [EMAIL PROTECTED] writes:
I repeated Tony's result (Win32):
Hmm, some delay in the signal being recognized in our Win32 signal
implementation? Why would that be?
regards, tom lane
---(end of broadcast)---
Tom Lane [EMAIL PROTECTED] wrote
Hmm, some delay in the signal being recognized in our Win32 signal
implementation? Why would that be?
I believe this is a disease for all platforms, not only Windows. This is
because the signals are asynchoronized. Think when you returned from
Cedric Berger [EMAIL PROTECTED] wrote
I tried to stop postgress using: 'su - postgres -c pg_ctl stop -swm
fast'
but that function never returns. Even kill -9 couldn't stop the process.
If repeatable, can you strace (maybe not called this in Solaris) what
postgres is doing?
Regards,
'k, 8.1.0 is bundled ... this is effectively RC2, so *please* look it
over, test it and make sure that we haven't missed anything ... official
release is on Tuesday the 8th, the intervening time is meant to allow Dave
time to get the Windows binary/installer ready, Devrim to get RPMs, Magnus
Andrew Dunstan wrote:
Qingqing Zhou wrote:
test=# LOG: received SIGHUP, reloading configuration files
test=# select setting from pg_settings where name =
'constraint_exclusion';
setting
-
off
(1 row)
test=# select setting from pg_settings where name =
'constraint_exclusion';
On Fri, 4 Nov 2005, Tony Caduto wrote:
hmm, I waited for at least 1 minute after doing the reload and it was
never updated. It seemed at the time that the only way to get a updated
pg_settings view was to actually restart the server. I plan on doing
some more testing on Saturday.
Did you
Tom Lane [EMAIL PROTECTED] wrote
Can anyone test 8.1RC1 on IRIX?
On a separate matter, I did a simple regression (--enable-cassert) of cvs
tip on SunOS 5.8, seems no problem. I found the only thing related in our
document is that SunOS 4 is not supported in 2001. Shall we add something
in
Otto Hirr [EMAIL PROTECTED] writes:
Trivia...
I heard a story many years ago that landed a programmer in prison...
He worked on the program that calculated interest that was to be
deposited into an account. Instead of rounding or truncating the
amount beyond what the bank wanted to use, he
Marc G. Fournier [EMAIL PROTECTED] writes:
'k, 8.1.0 is bundled ...
Seems like it's time to cut the REL 8.1 branch?
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
A libpqxx user just informed me that the anonymous CVS repository at
anoncvs.postgresql.org still contained a 2002 version of libpqxx in the
interfaces directory. I checked it out and otherwise it seems to be the
current source tree--at least I found an 8.1 version number somewhere.
Could
79 matches
Mail list logo
