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
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
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 ...
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
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.
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
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
[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
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
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 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.
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
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
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
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.
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
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
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 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
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.
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
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
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
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
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
[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
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
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
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
[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
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:
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
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
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
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
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
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?
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
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
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
40 matches
Mail list logo
