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
> > 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
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
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
> 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
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
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
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
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
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
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
> > 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
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
"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
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.
"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
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
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
"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
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
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.
--
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
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
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
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
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 <[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
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
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
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 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
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
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
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 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
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
-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.
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
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, 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
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
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
-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.
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 <
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
-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:
* 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
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:
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
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.
-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
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
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
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
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
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,
>
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 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
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
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
--
-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
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
-- 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
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
> -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
"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
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
70 matches
Mail list logo
