./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 average
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"
PG_FUNCT
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
confir
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
main()
{
double x[] = { 0.1, 0.11, 0.12, 0.13, 0.14, 0.15 };
int i,n;
for (i=0
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' st
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 wo
[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 cur
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.
Configure
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
http://develope
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 numb
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
> r
"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 whol
[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...
AI
> "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
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. K
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 wou
"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
> handle
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.
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,
> > >
> > 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 window
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
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, null-termina
> 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 represent
"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 dou
> >> 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 keepin
[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 b
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 assumpt
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 0x00
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 your
> -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] [PER
> 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 t
On 11/4/05, Martijn van Oosterhout 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 if you're
"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 ()
On 11/4/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Martijn van Oosterhout 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 sa
"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: d
Martijn van Oosterhout 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 really
is a restrict
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 s
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
On 10/13/05, Josh Berkus 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, eg, '12:13
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 hea
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 H
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
"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.
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 0x003b8946fb20 in strlen () from /lib64/tls/libc.so.6
> > > #
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 el
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
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
> pointles
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
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
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 cas
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 th
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
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 gre
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 ju
On 11/4/05, Martijn van Oosterhout 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 is deprecated
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 =
'constraint_exc
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 tran
"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
"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 r
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 row)
>
> 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 ...
Regar
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 c
"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
kill(
"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?
Rega
'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';
s
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.
>
Di
"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 somethin
"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 u
"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 someone
80 matches
Mail list logo
