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
"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
"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
"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
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
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
'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
"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
"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(
"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)--
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
>
> 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
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)
"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
"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
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
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 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
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
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 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
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 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
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
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
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
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: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 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
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
> > > #
"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" <[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
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
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 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 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 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
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
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
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
"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
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
"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, 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
> 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
> -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
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
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
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
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
[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
"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
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
> 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 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
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
> > 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
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,
> > >
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.
"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
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
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
> "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
[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 slow the whol
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
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 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
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
>
[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
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
"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 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
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
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.
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
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
./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
80 matches
Mail list logo
