Re: [HACKERS] autovacuum causing numerous regression-test failures

[Andreas Pflug]

Tom Lane wrote:
>
> My objection here is basically that this proposal passed on the
> assumption that it would be very nearly zero effort to make it happen.
> We are now finding out that we have a fair amount of work to do if we
> want autovac to not mess up the regression tests, and I think that has
> to mean that the proposal goes back on the shelf until 8.3 development
> starts.  We are already overcommitted in terms of the stuff that was
> submitted *before* feature freeze.
>   

Kicking out autovacuum as default is a disaster, it took far too long to
get in the backend already (wasn't it planned for 8.0?).
You discuss this on the base of the regression tests, which obviously
run on installations that do _not_ represent standard recommended
installations. It's required for ages now to have vacuum running
regularly, using cron or so. The regression tests have to deal with that
default situation, in one way or the other (which might well mean "this
tables don't need vacuum" or "this instance doesn't need vacuum"). IMHO
blaming autovacuum for the test failures reverses cause and effect.

Missing vacuum was probably a reason for poor performance of many newbie
pgsql installations  (and I must admit that I missed installing the cron
job myself from time to time, though I _knew_ it was needed). As Magnus
already pointed out, all win32 installations have it on by default, to
take them to the safe side. Disabling it for modules a "retail" user
will never launch appears overreacting.

I can positively acknowledge that disabling autovacuum with a
pg_autovacuum row does work, I'm using it in production.

Regards,
Andreas


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[HACKERS] would like to stop it auto-starting on boot on HP-UX IPF

[Lee]

I have installed postgres.


I would like to stop it auto-starting on boot but I am not sure where
HP
UX postgres keeps these auto start settings/scripts.

I have searched everywhere. Can someone give me some guidence please.


This is what keeps starting


# ps -ef|grep postg
   sfmdb  2881  1594  0 19:20:02 ? 0:00 postgres: sfmdb LOGDB
[local] id
le
   sfmdb  1618  1617  0 19:18:09 ? 0:00 postgres: stats
collector proces
s
   sfmdb  1617  1594  0 19:18:09 ? 0:00 postgres: stats buffer
process
   sfmdb  2329  1594  0 19:19:00 ? 0:00 postgres: sfmdb LOGDB
[local] id
le
root 20809   978  1 09:47:17 pts/ta0:00 grep postg
# 


Thanks 


Lee


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] insert/update/delete returning and rules

[Jaime Casanova]

On 8/15/06, Tom Lane <[EMAIL PROTECTED]> wrote:

I'm tempted to suggest that the RETURNING commands might need to be
separate rule events, and that to support this you'd need to write
an additional rule:

CREATE RULE r1 AS ON INSERT RETURNING TO myview DO INSTEAD
INSERT ... RETURNING ...


This is something for 8.3?

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
  Richard Cook

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg

[Michael Meskes]

On Mon, Aug 28, 2006 at 11:03:25PM +0200, Joachim Wieland wrote:
> What about changing those lines before diffing the files? This is already
> done for different default port settings in order to keep output files in
> sync.

I applied that patch. Let's see how it goes.

Needless to say it worked for me and it's reaonable to have the paths
shortened IMO.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] ECPG connection target formats

[Michael Meskes]

On Sat, Aug 26, 2006 at 10:00:42PM -0600, Michael Fuhr wrote:
> 1. [EMAIL PROTECTED]:port]

Fixed.

> 2. tcp:postgresql://hostname[:port][/dbname][?options]
> 
> This suggests that tcp:postgresql://hostname[:port] should work
> without specifying /dbname, and indeed it does work when the

Fixed.

> 3. unix:postgresql://hostname[:port][/dbname][?options]

Should work too.

> 4. "an SQL string literal containing one of the above forms"

Fixed.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] autovacuum causing numerous regression-test failures

[Tom Lane]

Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> My objection here is basically that this proposal passed on the
>> assumption that it would be very nearly zero effort to make it happen.

> Kicking out autovacuum as default is a disaster, it took far too long to
> get in the backend already (wasn't it planned for 8.0?).

If it's so "disastrous" to not have it, why wasn't it even proposed
until two weeks after feature freeze?  Sorry, I'm not buying this
argument.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg

[Tom Lane]

Michael Meskes <[EMAIL PROTECTED]> writes:
> On Mon, Aug 28, 2006 at 11:03:25PM +0200, Joachim Wieland wrote:
>> What about changing those lines before diffing the files? This is already
>> done for different default port settings in order to keep output files in
>> sync.

> I applied that patch. Let's see how it goes.

I don't see that patch actually committed, and HEAD still fails the ecpg
tests in a VPATH build.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] [COMMITTERS] pgsql: Second try committing the path changes.

[Tom Lane]

[EMAIL PROTECTED] (Michael Meskes) writes:
> Second try committing the path changes.

Ah, this looks better.  I get clean passes on both HPPA in-tree and
Fedora x86_64 VPATH builds, so I think you've finally fixed all the
issues.  Congrats!

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] autovacuum causing numerous regression-test failures

[Peter Eisentraut]

Am Dienstag, 29. August 2006 11:14 schrieb Andreas Pflug:
> already pointed out, all win32 installations have it on by default, to
> take them to the safe side. Disabling it for modules a "retail" user
> will never launch appears overreacting.

Well, the really big problem is that autovacuum may be connected to a database 
when you want to drop it.  (There may be related problems like vacuuming a 
template database at the wrong time.  I'm not sure how that is handled.)  I 
think this is not only a problem that is specific to the regression testing 
but a potential problem in deployment.  I have opined earlier how I think 
that should behave properly, but we're not going to change that in 8.2.

The other problems that were mentioned are pretty easy to work around by 
setting stats_row_level to off on the fly, but that doesn't stop autovacuum 
from connecting.

The good thing is that we have collected plenty of interesting data in the 
last 24 hours which will make for plenty of development work next time 
around. :)

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg

[Michael Meskes]

On Tue, Aug 29, 2006 at 08:55:10AM -0400, Tom Lane wrote:
> I don't see that patch actually committed, and HEAD still fails the ecpg
> tests in a VPATH build.

Argh! The second time my system doesn't commit all changes. I wonder
what's going wrong. I tried again. Do you see it now? 

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg

[Tom Lane]

Michael Meskes <[EMAIL PROTECTED]> writes:
> Argh! The second time my system doesn't commit all changes. I wonder
> what's going wrong.

Wow, I've never had CVS miss a commit (at least not through *its* error
;-)).  Better look into that.

> I tried again. Do you see it now? 

Yeah, looks good now.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] tsvector/tsearch equality and/or portability issue

[Teodor Sigaev]

comparing the same vectors, but stripped. Oddly, the unstripped comparisons all
pass, which is not consistant with what I am seeing in my database. However,
I'm yet unable to reproduce those problems.


Fixed: strncmp was called with wrong length parameter.



It looks to me like tsvector comparison may be too strong.  The strip()
function evidently thinks that it's OK to rearrange the string chunks
into the same order as the WordEntry items, which suggests to me that
the "pos" fields are not really semantically significant.  But 
silly_cmp_tsvector() considers that a difference in pos values is

important.  I don't understand the data structure well enough to know
which one to believe, but something's not consistent here.


You are right: Pos really means position of lexeme itself in a tail of tsvector 
structure. So, it's removed from comparison.


--
Teodor Sigaev   E-mail: [EMAIL PROTECTED]
   WWW: http://www.sigaev.ru/

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] integration of pgcluster into postgresql

[Chahine Hamila]

Yes, I forgot to include hackers on that mail. Anyway,
relax Jim, I'm not trying to invade anyone's turf
here. There seems to be support for the idea of
providing an interface plug for replication modules,
which is fine with me. If you have any constructive
criticism towards that, I'd be most happy to consider
it and try to find an accomodation.

Best regards

--- Jim Nasby <[EMAIL PROTECTED]> wrote:

> Adding -hackers back in...
> 
> -Original Message-
> >From: Chahine Hamila
> [mailto:[EMAIL PROTECTED]
> >Sent: Fri 8/25/2006 8:36 PM
> >To: Jim Nasby
> >Subject: Re: [HACKERS] integration of pgcluster
> into postgresql
> > 
> >> First, you need to review all the past discussion
> >> about the very
> >> intentional decision not to build any replication
> >> into the core
> >> database.
> >
> >I would gladly do so. Can you send me any pointer?
> 
> I don't really have any handy, but try searching the
> hackers archive for 'replication'.
> 
>  
> >> Second, pgcluster is (AFAIK) command-based
> >> replication, which has some
> >> very, very serious drawbacks. If PostgreSQL were
> to
> >> include a
> >> replication solution, I'd certainly hope it
> wouldn't
> >> be command-based.
> >
> >It's better than no replication at all... It's good
> >enough for many uses.
> 
> As is Slony. And dbmirror. And pgpool. So where do
> we draw the line? Should we include all four?
> 
> ---(end of
> broadcast)---
> TIP 3: Have you checked our extensive FAQ?
> 
>http://www.postgresql.org/docs/faq
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---(end of broadcast)---
TIP 6: explain analyze is your friend

[HACKERS] python / 7.4 / FC5 / x86_64

[Andrew Dunstan]

I see that my new 64 bit / FC5  buildfarm member died on building 7.4 
due to the following line in the configure script:


python_configdir="${python_execprefix}/lib/python${python_version}/config"

On my machine, this should be lib64, not lib. In fact, both 
/usr/lib/python2.4 and /usr/lib64/python2.4 exist, so I can't just use a 
soft link to get around this.


I could just disable building with python on that branch on my buildfarm 
member. Or we could fix it in the config script properly, although I am 
not sure how possible that is, nor if it is at all worth it - 
backporting the 8.0 changes would be the way I guess.


Thoughts?

cheers

andrew

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg

[Michael Meskes]

On Tue, Aug 29, 2006 at 09:56:58AM -0400, Tom Lane wrote:
> Wow, I've never had CVS miss a commit (at least not through *its* error
> ;-)).  Better look into that.

No, it's probably my fault, but I fail to see what I made wrong. I
changed the file, then ran an cvs update and then committed.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] python / 7.4 / FC5 / x86_64

[Peter Eisentraut]

Am Dienstag, 29. August 2006 16:25 schrieb Andrew Dunstan:
> On my machine, this should be lib64, not lib. In fact, both
> /usr/lib/python2.4 and /usr/lib64/python2.4 exist, so I can't just use a
> soft link to get around this.

Ideally, we would get Python to tell us the right location, because "use lib64 
if it exists" isn't the right solution.

Is this fixed somewhere post 7.4?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] python / 7.4 / FC5 / x86_64

[Joshua D. Drake]

Andrew Dunstan wrote:


I see that my new 64 bit / FC5  buildfarm member died on building 7.4 
due to the following line in the configure script:


python_configdir="${python_execprefix}/lib/python${python_version}/config"

On my machine, this should be lib64, not lib. In fact, both 
/usr/lib/python2.4 and /usr/lib64/python2.4 exist, so I can't just use a 
soft link to get around this.


I could just disable building with python on that branch on my buildfarm 
member. Or we could fix it in the config script properly, although I am 
not sure how possible that is, nor if it is at all worth it - 
backporting the 8.0 changes would be the way I guess.


Thoughts?


Use a different CPP_FLAGS? That is what we have to do on our hosting-two 
box.




cheers

andrew

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] python / 7.4 / FC5 / x86_64

[Andrew Dunstan]

Peter Eisentraut wrote:

Am Dienstag, 29. August 2006 16:25 schrieb Andrew Dunstan:
  

On my machine, this should be lib64, not lib. In fact, both
/usr/lib/python2.4 and /usr/lib64/python2.4 exist, so I can't just use a
soft link to get around this.



Ideally, we would get Python to tell us the right location, because "use lib64 
if it exists" isn't the right solution.


Is this fixed somewhere post 7.4?

  


Yes, but it was never backported. See:

http://developer.postgresql.org/cvsweb.cgi/pgsql/config/python.m4

cheers

andrew

---(end of broadcast)---
TIP 6: explain analyze is your friend

[HACKERS] GRANT role docs inconsistency

[Magnus Hagander]

The manual says:
GRANT role [, ...]
TO { username | GROUP groupname | PUBLIC } [, ...] [ WITH ADMIN
OPTION ]

But:
postgres=# GRANT test TO GROUP test2;
ERROR:  syntax error at or near "GROUP" at character 15
LINE 1: GRANT test TO GROUP test2;


Either I can't read the docs :-), or the docs are wrong, or the code is
wrong...

//Magnus


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] integration of pgcluster into postgresql

[Jim C. Nasby]

On Tue, Aug 29, 2006 at 07:19:09AM -0700, Chahine Hamila wrote:
> Yes, I forgot to include hackers on that mail. Anyway,
> relax Jim, I'm not trying to invade anyone's turf
> here. There seems to be support for the idea of
> providing an interface plug for replication modules,
> which is fine with me. If you have any constructive
> criticism towards that, I'd be most happy to consider
> it and try to find an accomodation.

Well, the big challenge there is that each replication system uses a
different methodology, so you're unlikely to come up with anything that
would be common between any two systems.

I think the best bet is to look for things that can be added that are
either difficult or impossible to do outside the backend, or that have
use beyond just replication.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] would like to stop it auto-starting on boot on HP-UX IPF

[Andrew Hammond]

1) This has nothing to do with hacking the internals of Postgres, which
means you are asking on the wrong list.
2) This has little to do with the Postgres scripts, but instead has to
do with the bootup scripts for the OS and or possibly some HP-UX
package manager. It is unlikely that the Postgres community is the
right one to ask about this, although there may be some HP-UX users
around here. Have you looked for an HP-UX community?

Drew


Lee wrote:
> I have installed postgres.
>
>
> I would like to stop it auto-starting on boot but I am not sure where
> HP
> UX postgres keeps these auto start settings/scripts.
>
> I have searched everywhere. Can someone give me some guidence please.
>
>
> This is what keeps starting
>
>
> # ps -ef|grep postg
>sfmdb  2881  1594  0 19:20:02 ? 0:00 postgres: sfmdb LOGDB
> [local] id
> le
>sfmdb  1618  1617  0 19:18:09 ? 0:00 postgres: stats
> collector proces
> s
>sfmdb  1617  1594  0 19:18:09 ? 0:00 postgres: stats buffer
> process
>sfmdb  2329  1594  0 19:19:00 ? 0:00 postgres: sfmdb LOGDB
> [local] id
> le
> root 20809   978  1 09:47:17 pts/ta0:00 grep postg
> # 
> 
> 
> Thanks 
> 
> 
> Lee


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] autovacuum causing numerous regression-test failures

[Andreas Pflug]

Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
>   
>> Tom Lane wrote:
>> 
>>> My objection here is basically that this proposal passed on the
>>> assumption that it would be very nearly zero effort to make it happen.
>>>   
>
>   
>> Kicking out autovacuum as default is a disaster, it took far too long to
>> get in the backend already (wasn't it planned for 8.0?).
>> 
>
> If it's so "disastrous" to not have it, why wasn't it even proposed
> until two weeks after feature freeze? 
To me, this proposal was just too obvious, for reasons already discussed
earlier.

Regards,
Andreas


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] autovacuum causing numerous regression-test failures

[Andreas Pflug]

Peter Eisentraut wrote:
> Am Dienstag, 29. August 2006 11:14 schrieb Andreas Pflug:
>   
>> already pointed out, all win32 installations have it on by default, to
>> take them to the safe side. Disabling it for modules a "retail" user
>> will never launch appears overreacting.
>> 
>
> Well, the really big problem is that autovacuum may be connected to a 
> database 
> when you want to drop it.  (There may be related problems like vacuuming a 
> template database at the wrong time.  I'm not sure how that is handled.)  I 
> think this is not only a problem that is specific to the regression testing 
> but a potential problem in deployment.  I have opined earlier how I think 
> that should behave properly, but we're not going to change that in 8.2.
>   
Don't these issues hit a cron scheduled vacuum as well?

Regards,
Andreas


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] would like to stop it auto-starting on boot on HP-UX

[Andrew Dunstan]

Andrew Hammond wrote:

1) This has nothing to do with hacking the internals of Postgres, which
means you are asking on the wrong list.
2) This has little to do with the Postgres scripts, but instead has to
do with the bootup scripts for the OS and or possibly some HP-UX
package manager. It is unlikely that the Postgres community is the
right one to ask about this, although there may be some HP-UX users
around here. Have you looked for an HP-UX community?

  



We do have one notable HP-UX user ;-)

cheers

andrew

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] stats test on Windows is now failing repeatably?

[Stefan Kaltenbrunner]

Tom Lane wrote:
> I just looked over the buildfarm results and was struck by the
> observation that the stats regression test, which lately had been
> failing once-in-a-while on Windows and never anywhere else, has a
> batting average of 0-for-10-or-so over the past 24 hours on the Windows
> buildfarm machines.  I still have no idea what the real problem is there
> --- but since it suddenly seems to have gotten very repeatable, I trust
> someone with a Windows box and a debugger will get after it before the
> source code drifts again.

maybe it's worth pointing out that leveret(fedora core5/x86_64/icc)
manages to trigger that too on occassion - so maybe it is not a "windows
only" bug:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=leveret&dt=2006-08-17%2008:30:01
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=leveret&dt=2006-08-10%2000:30:02


Stefan

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] [COMMITTERS] pgsql: Second try committing the path changes.

[Chris Browne]

[EMAIL PROTECTED] (Tom Lane) writes:
> [EMAIL PROTECTED] (Michael Meskes) writes:
>> Second try committing the path changes.
>
> Ah, this looks better.  I get clean passes on both HPPA in-tree and
> Fedora x86_64 VPATH builds, so I think you've finally fixed all the
> issues.  Congrats!

Ah.  So this would have caused a bunch of problems in compiling
src/interfaces/ecpg/test/connect/test1.pgc???

I'm not sure I'm seeing it in CVS; perhaps this waits some time before
getting completely public?
-- 
let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/languages.html
"Unfortunately, because the wicked sorcerers of Silikonn' Vahlli hated
freedom, they devised  clever signs and wonders to  achieve the mighty
Captive User Interface, also known as the Prison for Idiot Minds."
-- Michael Peck <[EMAIL PROTECTED]>

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init

[Devrim GUNDUZ]

Hello,

On Sat, 2006-08-26 at 19:16 -0400, Andrew Dunstan wrote:
> Well, in the case of RPMS built with the pgfoundry pgsqlrpms project 
> init script, it looks to me like it is already disabled: see 
> http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsqlrpms/patches/8.2/postgresql.init?rev=1.2&content-type=text/x-cvsweb-markup

This is a pre-pre-alpha; and may be reverted in stable release. I'm just
trying to find a better way for initdb troubles.

Regards,
-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/



signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] [COMMITTERS] pgsql: Second try committing the path changes.

[Jaime Casanova]

On 8/29/06, Chris Browne <[EMAIL PROTECTED]> wrote:

[EMAIL PROTECTED] (Tom Lane) writes:
> [EMAIL PROTECTED] (Michael Meskes) writes:
>> Second try committing the path changes.
>
> Ah, this looks better.  I get clean passes on both HPPA in-tree and
> Fedora x86_64 VPATH builds, so I think you've finally fixed all the
> issues.  Congrats!

Ah.  So this would have caused a bunch of problems in compiling
src/interfaces/ecpg/test/connect/test1.pgc???

I'm not sure I'm seeing it in CVS; perhaps this waits some time before
getting completely public?


i'm seeing this error when compiling HEAD (updated at ago 29 15:16)

make[5]: Entering directory
`/home/postgres/PG_RELEASES/pgsql-8.2uv/src/interfaces/ecpg/test/connect'
../../preproc/ecpg -I./../../include -o test1.c -I. test1.pgc
test1.pgc:29: ERROR: syntax error at or near "@"
make[5]: *** [test1.c] Error 3
make[5]: *** Deleting file `test1.c'

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
  Richard Cook

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] [PATCHES] Another VPATH patch for ecpg

[Martijn van Oosterhout]

On Tue, Aug 29, 2006 at 04:29:28PM +0200, Michael Meskes wrote:
> On Tue, Aug 29, 2006 at 09:56:58AM -0400, Tom Lane wrote:
> > Wow, I've never had CVS miss a commit (at least not through *its* error
> > ;-)).  Better look into that.
> 
> No, it's probably my fault, but I fail to see what I made wrong. I
> changed the file, then ran an cvs update and then committed.

Umm, just looking at the CVS commit logs gives this odd result:

http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.4&r2=1.5
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.5&r2=1.6
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.6&r2=1.7

(the diffs between revisions 1.4, 1.5, 1.6 and 1.7 for the
compat_informix-dec_test.c.diff file).

It changed and changed back again, very odd...

Hope this helps,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to 
> litigate.


signature.asc
Description: Digital signature

Re: [HACKERS] [PATCHES] updated patch for selecting large results sets in psql using cursors

[Tom Lane]

<[EMAIL PROTECTED]> writes:
> here comes the latest version (version 7) of the patch to handle large
> result sets with psql.  As previously discussed, a cursor is used
> for SELECT queries when \set FETCH_COUNT some_value > 0

Applied with revisions ... I didn't like the fact that the code was
restricted to handle only unaligned output format, so I fixed print.c
to be able to deal with emitting output in sections.  This is not
ideal for aligned output mode, because we compute column widths
separately for each FETCH group, but all the other output modes work
nicely.  I also did a little hacking to make \timing and pager output
work as expected.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] TODO Request

[Joshua D. Drake]

Hello,

Can we get:

Multiple table indexes (for uniqueness across partitions for example)
Auto creations of partitions
Hash partitioning
Key partitioning
Sub partitioning


Added to the TODO list?

Joshua D. Drake

--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

[HACKERS] Santa Clara Pg Training Event

[Michael Loftis]

I've been waiting for atleast one more person to sign up for the training 
so OTG can confirm this class down there, they said that some of the 
internal hackers had requested the course out there, so I wanted to ping 
everyone here.  I know, kinda off topic and all, but the event is coming up 
soon and I have to either book airfare, or not, this week.


Right now they only need 1-2 more people to make the course a go. 



TIA!

--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Santa Clara Pg Training Event

[Joshua D. Drake]

Michael Loftis wrote:
I've been waiting for atleast one more person to sign up for the 
training so OTG can confirm this class down there, they said that some 
of the internal hackers had requested the course out there, so I wanted 
to ping everyone here.  I know, kinda off topic and all, but the event 
is coming up soon and I have to either book airfare, or not, this week.


Right now they only need 1-2 more people to make the course a go. 



You actually may have better luck on -general, -novice or -admin.

Sincerely,

Joshua D. Drake



TIA!

--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] stats test on Windows is now failing repeatably?

[ITAGAKI Takahiro]

Tom Lane <[EMAIL PROTECTED]> wrote:

> I just looked over the buildfarm results and was struck by the
> observation that the stats regression test, which lately had been
> failing once-in-a-while on Windows and never anywhere else, has a
> batting average of 0-for-10-or-so over the past 24 hours on the Windows
> buildfarm machines.

I tested HEAD on Windows and saw some Windows-specific logs.

LOG:  Windows fopen("base/16384/pg_internal.init","rb") failed: code 2, errno 2
LOG:  Windows fopen("global/pgstat.stat","rb") failed: code 32, errno 13

The code 2 means ERROR_FILE_NOT_FOUND, "The system cannot find the file
specified." and the code 32 means ERROR_SHARING_VIOLATION, "The process
cannot access the file because it is being used by another process."

We use the tmpfile-and-rename trick on both pg_internal.init and pgstat.stat.
Are there any incompatible behavior in the trick between POSIX and Windows?

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center



---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] TODO Request

[Tom Lane]

"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Can we get:

> Multiple table indexes (for uniqueness across partitions for example)
> Auto creations of partitions
> Hash partitioning
> Key partitioning
> Sub partitioning

> Added to the TODO list?

Perhaps a certain amount of specificity as to what these mean,
and why we need them, would be appropriate.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Autovacuum on by default?

[Josh Berkus]

Peter,

> OK, it seems that while everyone wants autovacuum be more aggressive by
> default, no one has any good data to support one setting or another.  I
> so I suggest that we just cut scale factor and base threshold in half
> right now (so it'd be 0.2, 0.1, 500, 250) and see about a
> better-researched setting for the next release.

I'd recommend actually 0.4 and 0.2 and 200 and 100.  I think that 20% and 10% 
are too aggresive.  0.4 and 0.2 are what I've been using in production on 
many machines.  On the other hand, I think that the thresholds are much too 
high -- that means that many small tables may never get vacuumed at all, even 
after 100% row replacement.

I'll admit, however, that I don't have test data to support this.  
Unfortunately we never got to good Autovac tests on the STP before it went 
down.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Autovacuum on by default?

[Josh Berkus]

Folks,

> all, even after 100% row replacement.

Er, "even after 1000% row replacement."

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] autovacuum causing numerous regression-test failures

[Josh Berkus]

Folks,

My vote is with Peter and Tom on not putting it in.  We needed to discuss/test 
this well before feature freeze if we really wanted to do it.

Here's what needs to be resolved:
a) make autovaccum play nice with the regression tests
b) come up with default threshold/multiplier values which are backed by test 
data

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] TODO Request

[Joshua D. Drake]

Tom Lane wrote:

"Joshua D. Drake" <[EMAIL PROTECTED]> writes:

Can we get:


Well this should be fun.




Multiple table indexes (for uniqueness across partitions for example)
Auto creations of partitions


This would be something like:

create table foo () partition by ...


Hash partitioning


Partitioning by HASH is used primarily to ensure an even distribution of 
data among a predetermined number of partitions.



Key partitioning


Partitioning by key is similar to partitioning by hash, except that 
where hash partitioning employs a user-defined expression.



Sub partitioning




Subpartitioning — also known as composite partitioning — is the further 
division of each partition in a partitioned table. (partitions that have 
partitions)




Added to the TODO list?


Perhaps a certain amount of specificity as to what these mean,
and why we need them, would be appropriate.


For reference I am directly apply my fair use rights to the above per 
the MySQL development docs. Reference below:


http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

Yes I am fully aware that we don't need to do something just because 
MySQL does it. However, Oracle has similar functionality and I would 
like to see us keep up :)


Of course I would like it to be done correctly :)

Sincerely,

Joshua D. Drake




regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] TODO Request

[Joshua D. Drake]

Tom Lane wrote:

"Joshua D. Drake" <[EMAIL PROTECTED]> writes:

Can we get:



Multiple table indexes (for uniqueness across partitions for example)
Auto creations of partitions
Hash partitioning
Key partitioning
Sub partitioning



Added to the TODO list?


Perhaps a certain amount of specificity as to what these mean,
and why we need them, would be appropriate.


Further on this is an additional reference:

http://www.psoug.org/reference/partitions.html

We should also probably add:

Allow planner to correctly use indexes on min/max across partitions

Sincerely,

Joshua D. Drake




regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly