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
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
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 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?
http://www.postgresql.org/doc
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-re
"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 wha
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 o
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
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
soo
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.
<[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
res
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 wr
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
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&conten
[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 th
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
> buildf
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 unli
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
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 disa
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 c
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
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
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
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/pyth
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 "u
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.
Micha
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/py
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
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 comparis
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.
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
--
Mi
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
[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
--
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. L
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 a
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.
>
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 f
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 ...
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
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 h
40 matches
Mail list logo
