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.
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 ze
> -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]>,
> "Rob
Hi guys,
I saw a strange behaviour on one of the production boxes. The
pg_stat_activity shows a process as 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.
procpid |
>>> 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 i
>>> 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 b
"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 t
> -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]>,
> "Ro
>>> 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,
> -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
>>> 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: 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]>,
> "Rob
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 t
"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
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
lim
> 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 like
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
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
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'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.
>>> 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
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 timest
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
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 new
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
b
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 w
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
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
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
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 pe
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 m
>>> 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 boo
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 ev
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 s
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 sy
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
> 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, Custo
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 versio
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
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 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.
>
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.
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 a
"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, AT
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.
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.
>
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 he
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
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 au
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
attr
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
51 matches
Mail list logo
