Hi,
I managed to get most of 8.3 built with VS2008EE last night. Ii had to
change some references to msbuild to vsbuild, which I guess is expected
but one compile issue surprised me.
I had to change
#ifdef IPV6_V6ONLY
at backend/libpq/pqcomm.c:386
to:
#if defined(IPV6_V6ONLY) && (!define
"Richard Wang" <[EMAIL PROTECTED]> writes:
> I expected 0 ^ 123.3 to be 0, but it reported error as follows
> postgres=# select 0 ^ 123.3;
> ERROR: cannot take logarithm of zero
Hmm, seems like the numeric and float8 power operators don't agree
about 0^0 either...
regards
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Richard Wang
> Sent: Tuesday, March 11, 2008 7:38 PM
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] bug in numeric_power() function
>
> I expected 0 ^ 123.3 to be 0, but it repor
I expected 0 ^ 123.3 to be 0, but it reported error as follows
postgres=# select 0 ^ 123.3;
ERROR: cannot take logarithm of zero
I find that there is a bug in numeric_power() function
the function caculates a ^ b based on the algorithm e ^ (lna * b)
as you see, ln0 is not valid
--
Sent via
-- Forwarded message --
From: longlong <[EMAIL PROTECTED]>
Date: 2008-3-12 9:42
Subject: Re: [HACKERS]COPY issue(gsoc project)
To: Neil Conway <[EMAIL PROTECTED]>
the first feature has been implementet. i used to ignore the pid column with
the command "copy tablename (columns) from
Is this still a TODO?
---
Simon Riggs wrote:
> On Mon, 2007-07-30 at 20:20 +0100, Simon Riggs wrote:
>
> > Jignesh Shah's scalability testing on Solaris has revealed further
> > tuning opportunities surrounding the start an
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce asks:
>>> Particularly consider using psql to restore a pg_dump
>>> dump --- are we going to add "SET statement_timeout=0"
>>> to the pg_dump file?
>
>> I hope not. That should be the user's choice.
> Would anyone want to limit the load t
On Tue, 2008-03-11 at 15:18 -0700, Neil Conway wrote:
> Note also that pg_bulkload currently does something analogous to this
> outside of the DBMS proper:
>
> http://pgbulkload.projects.postgresql.org/
Sorry, wrong project. I mean pgloader:
http://pgfoundry.org/projects/pgloader/
-Neil
--
Added to TODO for COPY:
o Allow COPY in CSV mode to control whether "" is treated as NULL
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php
---
Andrew Dunstan wrote:
>
> [redirecting to -hac
Added to pl/pgsql TODO:
o Improve logic of determining if an identifier is a a
variable or column name
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00436.php
---
Tom Lane wrote:
> I h
On Tue, 2008-03-11 at 20:56 +0800, longlong wrote:
> This would be a nice feature. Right now there are often applications
> where there is a data loading or staging table that ends up being
> merged with a larger table after some cleanup. Moving that data from
> the preperation area into the fina
Added to TODO:
* Research use of signals and sleep wake ups
http://archives.postgresql.org/pgsql-hackers/2007-07/msg3.php
---
Tom Lane wrote:
> While poking at the vacuum-launcher issue currently under discussion,
>
Added to TODO:
* Consider wither increasing BM_MAX_USAGE_COUNT improves performance
http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php
---
Gregory Stark wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Greg Sabino Mullane wrote:
>>> Particularly consider using psql to restore a pg_dump
>>> dump --- are we going to add "SET statement_timeout=0"
>>> to the pg_dump file?
>>
>> I hope not. That should be the user's choice.
> Would anyone want to limit the
I wrote:
> > I have a field whose distribution of frequencies of values is
> > roughly geometric, rather than flat.
> My problem is frequent
> > over-estimation of rows when restricting by this field with
> > values not known at plan time.
> Is there any facility already in PostgreSQL to hel
Joshua D. Drake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, 11 Mar 2008 16:17:53 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > Greg Sabino Mullane wrote:
> > > > Particularly consider using psql to restore a pg_dump
> > > > dump --- are we going to add "SET
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 11 Mar 2008 16:17:53 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Greg Sabino Mullane wrote:
> > > Particularly consider using psql to restore a pg_dump
> > > dump --- are we going to add "SET statement_timeout=0"
> > > to the pg_dum
Greg Sabino Mullane wrote:
> > Particularly consider using psql to restore a pg_dump
> > dump --- are we going to add "SET statement_timeout=0"
> > to the pg_dump file?
>
> I hope not. That should be the user's choice.
Would anyone want to limit the load time for pg_dump? I can hardly see
why.
Added to TODO:
o Consider normalizing fractions in postgresql.conf, perhaps
using '%'
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php
---
Heikki Linnakangas wrote:
> We have t
Added to TODO:
* Prefix command-line utilities like createuser with 'pg_'
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php
---
Alvaro Herrera wrote:
> Zdenek Kotala wrote:
> > Tom Lane wrote:
> > >Bruce
Added to TODO:
* Change memory allocation for multi-byte functions so memory is
allocated inside conversion functions
Currently we preallocate memory based on worst-case usage.
---
Tom Lane wrote:
> Tatsuo Ishii <[EMA
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Particularly consider using psql to restore a pg_dump
> dump --- are we going to add "SET statement_timeout=0"
> to the pg_dump file?
I hope not. That should be the user's choice.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC
Added to TODO:
* Consider sorting writes during checkpoint
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php
---
ITAGAKI Takahiro wrote:
> Greg Smith <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 11 Jun 2007
Added to TODO:
* Consider using a hash for joining to a large IN (VALUES ...) list
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php
---
Atul Deopujari wrote:
> Hi,
>
> Tom Lane wrote:
> > Neil Conway <
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 11 Mar 2008 10:46:23 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
And the -c version :) (thanks bruce)
Joshua D. Drake
- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> Maybe we can put additional test into configure and collect appropriate
>> data from buildfarm.
> It might be good to just check first if it returns realistic values for the
> example cases that have been mentioned.
Yeah, ple
Thanks for the info. I will make sure to direct these types of questions
to the 'general' list in the future.
Thanks again for your help!!!
Merlin Moncure wrote:
On Tue, Mar 11, 2008 at 1:26 PM, Joshua <[EMAIL PROTECTED]> wrote:
Hello,
I have a series of SQL Update statements. I would li
On Tue, Mar 11, 2008 at 1:53 PM, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> > I have a series of SQL Update statements. I would like to write a
> > function which runs all of the SQL Update statements one at a time, in
> > order from top to bottom. Can somebody share the basic syntax that I
On Tue, Mar 11, 2008 at 1:26 PM, Joshua <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have a series of SQL Update statements. I would like to write a
> function which runs all of the SQL Update statements one at a time, in
> order from top to bottom. Can somebody share the basic syntax that I
> wou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
O.k. this appeared easy enough for even me to do it. So I did. It seems
to work but I wasn't 100% positive on "where" I put the code changes.
Please take a look.
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company since 1997: http://www.
Added to TODO:
* Add temporal versions of generate_series()
http://archives.postgresql.org/pgsql-hackers/2007-04/msg01180.php
---
Jim Nasby wrote:
> On May 6, 2007, at 8:07 PM, Tom Lane wrote:
> > Jim Nasby <[EMAIL PRO
Zdenek Kotala wrote:
> Yes, agree. It seems only ZFS is OK at this moment and if somebody sets
> 32TB he gets nonsegment mode anyway.
Surely if you set the segment size to INT64_MAX, you will get nonsegmented
behavior anyway, so two code paths might not be necessary at all.
> I looked into posix
On Tue, 11 Mar 2008, Magnus Hagander wrote:
How about we move it to the wiki. AFAIK we can still lock it down to who
can edit it if we want to
You should confirm you can get the editing granularity you want before
making too many plans here if this is important. The features for locking
dow
Hello,
I have a series of SQL Update statements. I would like to write a
function which runs all of the SQL Update statements one at a time, in
order from top to bottom. Can somebody share the basic syntax that I
would need to write the aforementioned function?
Please let me know.
Thanks
-
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I think current patch could stay in CVS and I will rip out non segment
> code path in a new patch.
Sure, I feel no need to revert what's applied. Have at it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hac
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> Hmm, AFAIR subsequent investigation led to the discovery that autovacuum
> >> is not affected by statement_timeout.
>
> > Right -- see
> > http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/8004
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Tom Lane napsal(a):
These examples suggest that maybe what we want is not so much a "no
segments ever" mode as a segment size larger than 1GB.
PS: ZFS is happy with 2^64bit size and UFS has 1TB file size limit
(depends on solaris
Cliff Nieuwenhuis <[EMAIL PROTECTED]> writes:
> I'm not sure how to ask this question. I have written a function, and with
> PostgreSQL 8.0.13 I can do a "\df+" and see something like this under Source
> Code:
> DECLARE
> result text;
> ...
> If I create the same functio
Tom Lane wrote:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > Tom Lane napsal(a):
> >> These examples suggest that maybe what we want is not so much a "no
> >> segments ever" mode as a segment size larger than 1GB.
>
> > PS: ZFS is happy with 2^64bit size and UFS has 1TB file size limit
> > (de
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> These examples suggest that maybe what we want is not so much a "no
>> segments ever" mode as a segment size larger than 1GB.
> PS: ZFS is happy with 2^64bit size and UFS has 1TB file size limit
> (depends on solaris version)
So
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Hmm, AFAIR subsequent investigation led to the discovery that autovacuum
>> is not affected by statement_timeout.
> Right -- see
> http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/80044/focus=93847
Or even more to
Tom Lane napsal(a):
"Zeugswetter Andreas OSB SD" <[EMAIL PROTECTED]> writes:
Exactly, e.g. AIX is one of those. jfs (not the newer jfs2) has an
option
to enable large files, which is not the default and cannot be changed
post crfs.
And even if it is enabled, jfs has a 64 Gb filesize limit !
Anyb
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I have added a TODO:
> >
> > > o Set up autovacuum to ignore statement_timeout set in
> > > postgresql.conf
> > >
> > > http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php
> >
> > and documented this behavio
Alvaro Herrera wrote:
> Hmm, AFAIR subsequent investigation led to the discovery that autovacuum
> is not affected by statement_timeout.
Right -- see
http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/80044/focus=93847
So your documentation changes are incorrect.
--
Alvaro Herrera
Bruce Momjian wrote:
>
> I have added a TODO:
>
> > o Set up autovacuum to ignore statement_timeout set in
> > postgresql.conf
> >
> > http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php
>
> and documented this behavior with the attached patch; backpatched to
Added to TODO:
* Consider adding buffers the BGW finds reusable to the free list
http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php
* Automatically tune bgwriter_delay based on activity rather then using a
fixed interval
http://archives.postgresql.org/pgsql-hackers/2007-04
I have added a TODO:
> o Set up autovacuum to ignore statement_timeout set in
> postgresql.conf
>
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php
and documented this behavior with the attached patch; backpatched to 8.3.X.
--
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
There's a small window between backend A committing and sending a
NOTIFY, and the time client B receives the notification from backend B
through the connection and reacts to it.
Sorry, I was unclear: the case that's of interest
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>>> To be honest, I didn't realize the receiver gets to know the PID of the
>>> sending process, but clearly it does. It seems mostly indifferent to me;
>>> it's not guaranteed t
On Fri, Mar 07, 2008 at 04:55:17PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> Why do we keep the TODO file with the source code? Wouldn't it make
> >> more sense to store it separately?
>
> > No idea --- it has always been there because it re
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
To be honest, I didn't realize the receiver gets to know the PID of the
sending process, but clearly it does. It seems mostly indifferent to me;
it's not guaranteed that the PID is valid by the time the client
application sees it
"Zeugswetter Andreas OSB SD" <[EMAIL PROTECTED]> writes:
> Exactly, e.g. AIX is one of those. jfs (not the newer jfs2) has an
> option
> to enable large files, which is not the default and cannot be changed
> post crfs.
> And even if it is enabled, jfs has a 64 Gb filesize limit !
> Anybody know ot
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think this needs to be treated as experimental until it's got a few
>> more than zero miles under its belt.
> OK, then maybe we should document that.
Agreed, but at this point we don't even know what hazards we need to
document.
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So I'm thinking that PREPARE TRANSACTION should throw an error if any
>> LISTEN or UNLISTEN is pending in the current transaction.
> For back-branches, I'm a bit hesitant to do that, as there might be
> applications that do LIS
On Mon, 10 Mar 2008, Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Applied with minor corrections.
Why is this not the default when supported?
Fear.
Maybe eventually, but right now I think it's too risky.
One point that I already found out the hard way is
> > Line 52:
> > #define WHITESPACE "\f\n\r\t\v" /* as defined by isspace() */
> >
> > We've defined whitespace as not including a space character :-/
>
> Yes, we fixed this on February 20 and the fix will appear in 8.3.1 and
> all back brances once a release is made.
Thanks. I should have check
It is an announcement of new version of SE-PostgreSQL.
Now v8.3 based SE-PostgreSQL is available
-
SE-PostgreSQL development team published v8.3 based SE-PostgreSQL at:
http://download.fedora.redhat.com/pub/fedora/linux/development
You can obtain the v8.3
Richard Huxton wrote:
> Richard Huxton wrote:
> >
> > Hmm - that does seem to be the case. I added a line to print "connstr"
> > along with the "."
> > waiting for server to startdbname=postgres port=5483 -i
> > connect_timeout=5.
> >
> > The code looks fine to my uneducated eye though
i want to paticipate in gsoc 2008.
here is my plan:
the red part is came from Greg Smith(thanks for Greg Smith's advice).
1.release8.2 make COPY TO can copy the output of an arbitrary SELECT
statement. so i think maybe COPY FROM can get data from output and 'insert
into' some column that designat
Hello,
I've seen that postgreSQL tries to follow sql standards as far as possible,
and that sometimes (often) brings it's own extentions. I've thought of one
concerning the sql command create table like.
As far as I've understood the documentation, one can create a table using
another table as a
On Mon, Mar 10, 2008 at 12:16:52AM -0700, David Fetter wrote:
> - Add to TODO: "Add SQLSTATE severity to PGconn return status."
Yes, please. I have recently been discussing this with
Andreas, Bernd and Peter at Linuxtage Chemnitz.
In GNUmed we want to be able to distinguish connection
errors due
Tom Lane wrote:
Does it make any sense to allow LISTEN or UNLISTEN in a prepared
transaction?
It's certainly not sensical for these actions to affect the backend that
actually executes the COMMIT PREPARED, in the sense of creating or
destroying pg_listener entries for it. But how can we say tha
Richard Huxton wrote:
Hmm - that does seem to be the case. I added a line to print "connstr"
along with the "."
waiting for server to startdbname=postgres port=5483 -i
connect_timeout=5.
The code looks fine to my uneducated eye though (bin/pg_ctl/pg_ctl.c
test_postmaster_connection
> Tatsuo Ishii wrote:
> > Hi,
> >
> > I have encountered a strange pg_ctl's behavior in 8.3.
> >
> > pg_ctl -w -o "-p 5432" start<-- works
> > pg_ctl -w -o "-i" start <-- works
> > pg_ctl -w -o "-p 5432 -i" start <-- doesn't work
> >
> > In the last case, even postmaster starts s
Richard Huxton wrote:
Tatsuo Ishii wrote:
Hi,
I have encountered a strange pg_ctl's behavior in 8.3.
pg_ctl -w -o "-p 5432" start<-- works
pg_ctl -w -o "-i" start<-- works
pg_ctl -w -o "-p 5432 -i" start<-- doesn't work
In the last case, even postmaster starts successfully, pg_ctl
Tatsuo Ishii wrote:
Hi,
I have encountered a strange pg_ctl's behavior in 8.3.
pg_ctl -w -o "-p 5432" start <-- works
pg_ctl -w -o "-i" start <-- works
pg_ctl -w -o "-p 5432 -i" start <-- doesn't work
In the last case, even postmaster starts successfully, pg_ctl keeps
trying to ma
Hi,
I have encountered a strange pg_ctl's behavior in 8.3.
pg_ctl -w -o "-p 5432" start<-- works
pg_ctl -w -o "-i" start <-- works
pg_ctl -w -o "-p 5432 -i" start <-- doesn't work
In the last case, even postmaster starts successfully, pg_ctl keeps
trying to make sure that postmaster actually
> > Why is this not the default when supported?
>
> Fear.
>
> Maybe eventually, but right now I think it's too risky.
>
> One point that I already found out the hard way is that sizeof(off_t)
= 8
> does not guarantee the availability of largefile support; there can
also
> be filesystem-level co
> > Why is this not the default when supported? I am wondering both
from the
> > point of view of the user, and in terms of development direction.
>
> Also it would get more buildfarm coverage if it were default. If it
> breaks something we'll notice earlier.
No we don't, because the buildfar
Tom Lane wrote:
> I think this needs to be treated as experimental until it's got a few
> more than zero miles under its belt.
OK, then maybe we should document that.
> I wouldn't be too surprised to
> find that we have to implement it as a run-time switch instead of
> compile-time, in order to
70 matches
Mail list logo
