On Thu, 2008-01-31 at 01:12 -0600, Decibel! wrote:
On Mon, Jan 28, 2008 at 09:09:13PM -0300, Alvaro Herrera wrote:
Decibel! wrote:
On Fri, Jan 25, 2008 at 11:40:19AM +, Simon Riggs wrote:
(for 8.4 ...)
I'd like to introduce triggers that fire when we issue a truncate:
Hi,
We are testing PostGreSQL 8.3 RC2 on our beta plateform and we are
facing some problems with plpgsql function.
Here's a failing test case, which worked well on postgresql 8.1 :
Create this function :
CREATE OR REPLACE FUNCTION test(param integer)
RETURNS text AS
$BODY$DECLARE
On Jan 31, 2008 1:33 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Re-reading the thread ... could that last point be significant? Are
all four of these boxen set to auto-accept updates from Redmond?
No. red_bat does not auto-accept anything.
For future reference, my BF members do
On Thu, Jan 31, 2008 at 08:28:21AM +, Dave Page wrote:
On Jan 31, 2008 1:33 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Re-reading the thread ... could that last point be significant? Are
all four of these boxen set to auto-accept updates from Redmond?
No. red_bat does not
On Thu, Jan 31, 2008 at 12:45:40AM -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Yes, I have found the problem. It is this line, which I am amazed hasn't
bitten us before:
next unless /^\d/;
The first field in the dumpbin output looks like a 3 digit hex number.
On Wed, Jan 30, 2008 at 09:59:38PM +0100, Magnus Hagander wrote:
Stephen Denne wrote:
I said...
On Windows XP, using Process Explorer with the lower pane showing
Handles, not all postgres.exe processes are including an Event
type with a description of what the process is doing.
I've had
Magnus Hagander wrote:
I also propose to have the gendefs.pl script save the dumpbin output so
this sort of problem will be easier to debug.
Agreed, but I suggest waiting till 8.4 is branched unless you are really
sure about this addition. We freeze for 8.3.0 in less than 24 hours.
Decibel! [EMAIL PROTECTED] writes:
CLUSTER isn't DDL. Most forms of ALTER TABLE are. And CREATE blah, etc.
Fwiw I would call CLUSTER DDL. Note that it does make a change that's visible
in the table definition afterwards.
There are plenty of DDL commands which modify data (CREATE INDEX, ATLER
On Wed, 2008-01-30 at 12:56 -0800, Dann Corbit wrote:
It's too bad that they have a restrictive license.
Perhaps there is an opportunity to create an information appliance
that contains a special build of PostgreSQL, a nice heap of super-speedy
disk, and a big pile of GPUs for sort and
On Thu, 2008-01-31 at 10:22 +, Gregory Stark wrote:
Decibel! [EMAIL PROTECTED] writes:
CLUSTER isn't DDL. Most forms of ALTER TABLE are. And CREATE blah, etc.
Fwiw I would call CLUSTER DDL. Note that it does make a change that's visible
in the table definition afterwards.
Is it
Decibel! escribió:
BTW, with autovacuum I don't really see why we should care about how
long analyze takes, though perhaps it should have a throttle ala
vacuum_cost_delay.
Analyze already has vacuum delay points (i.e. it is already throttled).
--
Alvaro Herrera
On Wed, Jan 30, 2008 at 08:27:47PM +, Gregory Stark wrote:
Christopher Browne [EMAIL PROTECTED] writes:
This was based on GPUSort:
http://gamma.cs.unc.edu/GPUSORT/
I looked briefly at GPUSort a while back. I couldn't see how to shoehorn into
POstgres the assumption that you're always
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, but keep in mind if we use synchronized_seqscans in pg_dump we will
have to recognize that GUC forever.
No, because it's being used on the query side, not in the emitted dump.
We have *never* promised that pg_dump version N could
Tom Lane wrote:
in fact, personally I'd like to make that case be a hard error,
rather than something people could override with -i.
+1 to this idea. TODO for 8.4?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom
Magnus Hagander [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
For now I'm going try to fix it by changing it to:
next unless $pieces[0] =~/^[A-F0-9]{3}$/;
Yeah, nice catch. Wouldn't surprise me if we actually had this problem
before, just that the dropped symbols were
Andrew Dunstan [EMAIL PROTECTED] writes:
Agreed, but I suggest waiting till 8.4 is branched unless you are really
sure about this addition. We freeze for 8.3.0 in less than 24 hours.
I am pretty damn sure it's OK. It's pretty low risk (change an unlink
call to a rename call) and even if
Simon Riggs escribió:
On Thu, 2008-01-31 at 11:20 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
in fact, personally I'd like to make that case be a hard error,
rather than something people could override with -i.
+1 to this idea. TODO for 8.4?
-1 without some more planning
On Thu, 2008-01-31 at 11:20 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
in fact, personally I'd like to make that case be a hard error,
rather than something people could override with -i.
+1 to this idea. TODO for 8.4?
-1 without some more planning about the effects and
Hi,
Le jeudi 31 janvier 2008, Tom Lane a écrit :
We have *never* promised that pg_dump version N could dump from server
version N+1 .., in fact, personally I'd like to make that case be a hard
error, rather than something people could override with -i.
Are you thinking about next major or
Dimitri Fontaine wrote:
-- Start of PGP signed section.
Hi,
Le jeudi 31 janvier 2008, Tom Lane a ?crit?:
We have *never* promised that pg_dump version N could dump from server
version N+1 .., in fact, personally I'd like to make that case be a hard
error, rather than something people
Am Donnerstag, 31. Januar 2008 schrieb Alvaro Herrera:
Effect: we would stop receiving complaints that an old pg_dump can talk
to a server that most likely is incompatible with it. People would
learn on the spot that they must install the newer pg_dump.
I think a more moderate measure might
Peter Eisentraut wrote:
Am Donnerstag, 31. Januar 2008 schrieb Alvaro Herrera:
Effect: we would stop receiving complaints that an old pg_dump can talk
to a server that most likely is incompatible with it. People would
learn on the spot that they must install the newer pg_dump.
I think a
On Wed, Jan 30, 2008 at 8:13 PM, in message
[EMAIL PROTECTED], Christopher
Browne [EMAIL PROTECTED] wrote:
There seems to be *plenty* of evidence out there that the performance
penalty would NOT be essentially zero.
I can confirm that I have had performance tank because of boosting
the
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
For now I'm going try to fix it by changing it to:
next unless $pieces[0] =~/^[A-F0-9]{3}$/;
Yeah, nice catch. Wouldn't surprise me if we actually had this problem
select to_char(date, '-mm-dd hh24:mi:ss.ms') as char,
date
from (select timestamp'2008-01-30 15:06:21.560' as date) sub
2008-01-30 15:06:21.560;2008-01-30 15:06:21.56
Why does the timestamp field truncate the 0 but when I show the
timestamp as a character in the default timestamp
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Agreed, but I suggest waiting till 8.4 is branched unless you are really
sure about this addition. We freeze for 8.3.0 in less than 24 hours.
I am pretty damn sure it's OK. It's pretty low risk (change an unlink
call
Hubert FONGARNAND [EMAIL PROTECTED] writes:
We are testing PostGreSQL 8.3 RC2 on our beta plateform and we are
facing some problems with plpgsql function.
Here's a failing test case, which worked well on postgresql 8.1 :
Really? I get the 'does not match' error in every release back to 7.3.
I'm sorry, you're right it fails too with older version of postgresql
Le jeudi 31 janvier 2008 à 10:35 -0500, Tom Lane a écrit :
Hubert FONGARNAND [EMAIL PROTECTED] writes:
We are testing PostGreSQL 8.3 RC2 on our beta plateform and we are
facing some problems with plpgsql function.
Le jeudi 31 janvier 2008, Tom Lane a écrit :
I'm thinking next major. In principle there could be cases where a
minor update could break pg_dump, but it seems unlikely enough that
it's not reasonable to embed such a policy in the code. As for
next major, though, the mere existence of the -i
Dimitri Fontaine [EMAIL PROTECTED] writes:
Le jeudi 31 janvier 2008, Tom Lane a écrit :
We have *never* promised that pg_dump version N could dump from server
version N+1 .., in fact, personally I'd like to make that case be a hard
error, rather than something people could override with -i.
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 31. Januar 2008 schrieb Alvaro Herrera:
Effect: we would stop receiving complaints that an old pg_dump can talk
to a server that most likely is incompatible with it. People would
learn on the spot that they must install the newer
On Thu, Jan 31, 2008 at 9:34 AM, in message
[EMAIL PROTECTED], Roberts,
Jon [EMAIL PROTECTED] wrote:
select to_char(date, '-mm-dd hh24:mi:ss.ms') as char,
date
from (select timestamp'2008-01-30 15:06:21.560' as date) sub
2008-01-30 15:06:21.560;2008-01-30 15:06:21.56
http://msdn2.microsoft.com/en-us/library/b842y285(VS.71).aspx
appears to
suggest that the size of the field is fixed.
That would imply that dumpbin fails at 4096 symbols per file. While I
surely wouldn't put it past M$ to have put in such a
limitation, I think
it's more likely that
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 31. Januar 2008 schrieb Alvaro Herrera:
Effect: we would stop receiving complaints that an old pg_dump can talk
to a server that most likely is incompatible with it. People would
learn on the spot that they must
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
It strikes me that the pattern needs to be {3,} or maybe just +.
I dunno what this column is measuring, but if we are past 0xA00
then surely 0x1000 is not far away.
http://msdn2.microsoft.com/en-us/library/b842y285(VS.71).aspx appears
Kevin Grittner [EMAIL PROTECTED] writes:
On Thu, Jan 31, 2008 at 9:34 AM, in message
[EMAIL PROTECTED], Roberts,
Jon [EMAIL PROTECTED] wrote:
These two fields should be consistent because they should be formatted
the same way.
Why would you think that?
Indeed the whole *point* of
Zeugswetter Andreas ADI SD wrote:
http://msdn2.microsoft.com/en-us/library/b842y285(VS.71).aspx
appears to
suggest that the size of the field is fixed.
That would imply that dumpbin fails at 4096 symbols per file. While I
surely wouldn't put it past M$ to have put in such a
Kevin Grittner wrote:
On Wed, Jan 30, 2008 at 8:13 PM, in message
[EMAIL PROTECTED], Christopher
Browne [EMAIL PROTECTED] wrote:
There seems to be *plenty* of evidence out there that the performance
penalty would NOT be essentially zero.
I can confirm that I have had performance tank
-Original Message-
From: Kevin Grittner [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 31, 2008 9:48 AM
To: Roberts, Jon; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] timestamp format bug
On Thu, Jan 31, 2008 at 9:34 AM, in message
[EMAIL PROTECTED],
Roberts,
Jon
On Thu, Jan 31, 2008 at 12:34 PM, in message
[EMAIL PROTECTED], Roberts,
Jon [EMAIL PROTECTED] wrote:
If not to_char, what is the preferred method to convert a timestamp to a
string?
Your original post showed to_char apparently doing what you wanted, no?
select to_char(date, '-mm-dd
On Thu, Jan 31, 2008 at 12:28 PM, in message
[EMAIL PROTECTED], Roberts,
Jon [EMAIL PROTECTED] wrote:
The default timestamp format appears to be -mm-dd hh24:mi:ss.ms
Not to me:
select now();
now
---
2008-01-31 12:31:40.568746-06
(1 row)
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 31, 2008 10:48 AM
To: Kevin Grittner
Cc: Roberts, Jon; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] timestamp format bug
Kevin Grittner [EMAIL PROTECTED] writes:
On Thu, Jan 31, 2008 at
-Original Message-
From: Kevin Grittner [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 31, 2008 12:33 PM
To: Roberts, Jon; pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] timestamp format bug
On Thu, Jan 31, 2008 at 12:28 PM, in message
[EMAIL PROTECTED],
Roberts,
Jon
Bruce Momjian [EMAIL PROTECTED] writes:
Dimitri Fontaine wrote:
-- Start of PGP signed section.
Hi,
Le jeudi 31 janvier 2008, Tom Lane a ?crit?:
We have *never* promised that pg_dump version N could dump from server
version N+1 .., in fact, personally I'd like to make that case be a
On Thu, Jan 31, 2008 at 12:45 PM, in message
[EMAIL PROTECTED], Roberts,
Jon [EMAIL PROTECTED] wrote:
So on your db, run this query:
select sub.t1, to_char(t1, '-mm-dd hh24:mi:ss.us') as char_t1
from
(
select timestamp'2008-01-31 12:31:40.50' as t1
) sub
I bet you get this:
On Thu, Jan 31, 2008 at 12:34 PM, in message
[EMAIL PROTECTED], Roberts,
Jon [EMAIL PROTECTED] wrote:
doesn't round the zeros off for timestamp
Sorry to have been so slow, but I think this is the crux of it:
A timestamp represents a moment in time, without storing any
precision
Hi guys,
I saw a strange behaviour on one of the production boxes. The
pg_stat_activity shows a process as IDLE and yet 'waiting' !!! On top of
it (understandably, since its IDLE), there are no entries for this pid in
pg_locks!
Following are the snapshots of the two system views.
-Original Message-
From: Kevin Grittner [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 31, 2008 1:47 PM
To: Roberts, Jon; pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] timestamp format bug
On Thu, Jan 31, 2008 at 12:45 PM, in message
[EMAIL PROTECTED],
Roberts,
Jon
On Thursday 31 January 2008 09:55, Kevin Grittner wrote:
On Wed, Jan 30, 2008 at 8:13 PM, in message
[EMAIL PROTECTED], Christopher
Browne [EMAIL PROTECTED] wrote:
There seems to be *plenty* of evidence out there that the performance
penalty would NOT be essentially zero.
I can
Yeah :) Thanks everyone who worked a lot for this release.
Forwarded Message
From: Bruce Momjian [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [COMMITTERS] pgsql: Stamp 8.3 in CVS.
Date: Fri, 1 Feb 2008 02:59:02 + (UTC)
Log Message:
---
Stamp 8.3 in CVS.
50 matches
Mail list logo
