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
attr
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
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 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 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.
>
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, AT
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
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.
>
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
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
> 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
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
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
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 m
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
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
>>> 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
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
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
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
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
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
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
>>> 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
> 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
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
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
"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
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
> -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
>>> 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,
>>> 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
> -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
"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
>>> 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
>>> 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
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 |
> -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
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
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.
51 matches
Mail list logo
