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 not
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
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 buildfarm does
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 started
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 make sure
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
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 keeps
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
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
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
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
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 checked the CVS
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 LISTEN in a
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 others that
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 relates
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 that the PID is
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 is
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
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 8.3.X.
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 behavior with the attached
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 !
Anybody
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 the
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 even on
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
(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 function on my
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/80044/focus=93847
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
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
-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:
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
would need
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
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
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, please just
-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:
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: 0x14964AC8
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
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
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_dump file?
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 help me
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 load time for
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 final
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
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
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 time for
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 and end
-- 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 reported
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, tom
69 matches
Mail list logo
