Tom,
On 8/29/05 9:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Did that. Set shmall first, shmall second, both together in one sysctl
command; no joy anywhere. Are you trying this on fully up-to-date
Tiger?
Did you try the values I sent earlier? If you set them both in
/etc/sysctl.conf and
On Mon, 2005-08-29 at 20:25 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I notice that Neil's patch regarding reducing the number of memory
allocations during aggregation operations isn't mentioned. It was
originally discussed in 8.0beta (2-3?) time.
What happened there?
Fixed in 8.0, 7.4 and 7.3 branches.
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
http://www.sigaev.ru/gist/concur.pl
http://www.sigaev.ru/gist/concur.sh
BTW, these scripts seem to indicate that there's a GIST or
contrib/intarray problem in the 8.0 branch. I was trying to use
On Mon, 2005-08-29 at 14:58 -0700, Varun Kacholia wrote:
I assume you realise that Bernoulli sampling is currently possibly using
the random() function and setseed() ?
Yes, select * from table where random() x, does the job.
I can't see why TABLESAMPLE effects a sequential scan *only*,
Am Dienstag, 30. August 2005 11:25 schrieb Teodor Sigaev:
Fixed in 8.0, 7.4 and 7.3 branches.
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
http://www.sigaev.ru/gist/concur.pl
http://www.sigaev.ru/gist/concur.sh
BTW, these scripts seem to indicate that there's a GIST or
Since 7.4 we have troubles with ltree (seldom corruption of buffer cache, not
on-disk), might this bug be somehow related to the ltree problem?
7.2 was rock-stable with ltree.
Not sure. Fixed bug was (@ - contains operation):
update wow set a = a || '{101}'::int[] where a @ '{1,2,3}';
select
Am Dienstag, 30. August 2005 12:19 schrieb Teodor Sigaev:
Since 7.4 we have troubles with ltree (seldom corruption of buffer cache,
not on-disk), might this bug be somehow related to the ltree problem? 7.2
was rock-stable with ltree.
Not sure. Fixed bug was (@ - contains operation):
This is from my Powerbook
in /etc/rc
sysctl -w kern.sysv.shmmax=512 kern.sysv.shmmin=1
kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=1024
I also had to up maxprocperuid to 200 to get buildfarm to run
I'm pretty sure shmall had to be increased to allow shmmax to be
On E, 2005-08-29 at 13:09 +0200, Andreas Pflug wrote:
Hannu Krosing wrote:
On P, 2005-08-28 at 22:23 +0200, Andreas Pflug wrote:
I'm currently testing pgAdmin support for slony, on pgsql CVS HEAD, and
encounter strange problems from time to time.
After dropping and recreating the
We have queries that use ltree for sorting too, the sort looks like this:
order by subpath(ltreefield, 0, nlevel(ltreefield) - 1)
But concurrency leads to a bug, that results in an sql-error:
ERROR: invalid positions
contrib_regression=# select nlevel(t), subpath(t, 0, nlevel(t)-1) from
Hi all,
You know how i can make a backup of database automatically? I have a script pg_dump.exe DBNAME -U USER FILE but i don't know how put the password. If i put -W password the command line say that i put more paramatrers that the program accept.
Best Regards
On Tue, 30 Aug 2005, Tom Lane wrote:
What we are left with turns out to be multiple occurrences of the first
pathology on exactly three buildfarm members:
ferret Cygwin
kuduSolaris 9, x86
dragonfly Solaris 9, x86
So what to make of this?
[EMAIL PROTECTED] wrote:
Hi all,
You know how i can make a backup of database automatically? I have a
script pg_dump.exe DBNAME -U USER FILE but i don't know how put
the password. If i put -W password the command line say that i put
more paramatrers that the program accept.
You
On Aug 30, 2005, at 12:37 AM, Tom Lane wrote:
Did that. Set shmall first, shmall second, both together in one
sysctl
command; no joy anywhere. Are you trying this on fully up-to-date
Tiger?
Just ran software update and (besides a couple apps) it had a
security update.
The slony log trigger saves execution plans, so any given connection
that has been used with a slony schema installed will have cached OIDs
referring to the sl_log_1 table. When you drop the schema, those OIDs
obviously go away. When you re-create the schema, and try to use the old
connection, it
Tom Lane [EMAIL PROTECTED] writes:
You could do something like
... type boolean using case when field1=0 then false else true end;
Or you could save typing and just use USING field10
Odd that everyone did a CASE for that.
--
greg
---(end of
Kris Jurka [EMAIL PROTECTED] writes:
On Tue, 30 Aug 2005, Tom Lane wrote:
What we are left with turns out to be multiple occurrences of the first
pathology on exactly three buildfarm members:
ferret Cygwin
kudu Solaris 9, x86
dragonflySolaris 9, x86
So what to
Teodor Sigaev [EMAIL PROTECTED] writes:
Is this something that can be fixed for 8.0.4?
Fixed in 8.0, 7.4 and 7.3 branches.
Excellent news. Thanks.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our
Simon Riggs wrote:
On Mon, 2005-08-29 at 20:25 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I notice that Neil's patch regarding reducing the number of memory
allocations during aggregation operations isn't mentioned. It was
originally discussed in 8.0beta (2-3?) time.
On Aug 29, 2005, at 12:41 PM, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Mon, Aug 29, 2005 at 11:30:46AM -0400, Tom Lane wrote:
20 buffers ... ugh. Obviously we are on the hairy edge of no longer
functioning at all in 1MB shared memory. I'm not sure there is a
whole
On Tue, Aug 30, 2005 at 10:23:49AM -0400, Bruce Momjian wrote:
2005-03-12 15:25 tgl
* contrib/intagg/int_aggregate.c,
contrib/intagg/int_aggregate.sql.in, doc/src/sgml/xaggr.sgml,
doc/src/sgml/xfunc.sgml, src/backend/executor/nodeAgg.c,
src/backend/utils/adt/int8.c:
Alvaro Herrera wrote:
On Tue, Aug 30, 2005 at 10:23:49AM -0400, Bruce Momjian wrote:
2005-03-12 15:25 tgl
* contrib/intagg/int_aggregate.c,
contrib/intagg/int_aggregate.sql.in, doc/src/sgml/xaggr.sgml,
doc/src/sgml/xfunc.sgml,
Bruce Momjian pgman@candle.pha.pa.us writes:
Alvaro Herrera wrote:
On Tue, Aug 30, 2005 at 10:23:49AM -0400, Bruce Momjian wrote:
I don't usually document internal API changes in the release notes.
Should I?
Doesn't this potentially affect user-defined aggregates?
I read it as something
Jeff,
On 8/30/05 5:28 AM, Jeff Trout [EMAIL PROTECTED] wrote:
Just ran software update and (besides a couple apps) it had a
security update.
I just did that to test this.
skittlebrau:~ postgres$ grep shm /etc/rc
Luke-Lonergans-Computer:~ lukelonergan$ cat /etc/sysctl.conf
[EMAIL PROTECTED] (David Parker) writes:
The slony log trigger saves execution plans, so any given connection
that has been used with a slony schema installed will have cached OIDs
referring to the sl_log_1 table. When you drop the schema, those OIDs
obviously go away. When you re-create the
Thomas F. O'Connell [EMAIL PROTECTED] writes:
On Aug 29, 2005, at 12:41 PM, Tom Lane wrote:
I just finished going through the initialization sequence to trace the
calculation of shared memory size, and what I find in CVS tip is that
it works out like this:
Should the new formulation be sent
Chris Browne [EMAIL PROTECTED] writes:
What is needed is to invalidate the cached execution plans.
Yeah. This is not really Slony's fault --- we need a general solution
to that in the backend. I think Neil was working on it, but I dunno
how far along he is.
regards,
Hello everybody!
I'm so sorry to post this simple question but I don't know what to do, the thing is I need to install postgresql 8.0.3 in red hat 9 but when I try to do it this errors appear:
[EMAIL PROTECTED] root]# rpm -ivh postgresql-server-8.0.3-1PGDG.i686.rpmwarning:
On Tue, Aug 30, 2005 at 12:45:18PM -0400, Chris Browne wrote:
[EMAIL PROTECTED] (David Parker) writes:
The slony log trigger saves execution plans, so any given connection
that has been used with a slony schema installed will have cached OIDs
referring to the sl_log_1 table. When you drop
Tom Lane wrote:
Yeah. This is not really Slony's fault --- we need a general solution
to that in the backend. I think Neil was working on it, but I dunno
how far along he is.
Yeah, I had wanted to get this into 8.1, but I couldn't find time. I
still plan to work on it for 8.2, unless
Also, kookaburra (AIX) has a problem with the stats test as well.
What is most puzzling to me is that it only happens with cc (not gcc).
And I can only get it to happen when running a cronjob for the
buildfarm. If I run it interactively, the stats collector will run
fine, or if I run the build
Rocco Altier [EMAIL PROTECTED] writes:
Also, kookaburra (AIX) has a problem with the stats test as well.
kookaburra's problem is entirely different, not intermittent in the
least. The error diff shows that stats collection is off, and its
postmaster log says
LOG: could not bind socket for
Alvaro Herrera wrote:
Unfortunately, it's not at all obvious how to accomplish that :-(.
I don't think it can be easily done with the current code. This is
plpgsql code, right? There are some ways to cause recompilation for
those, at least on the 8.1 code I'm looking at.
Well at least
[EMAIL PROTECTED] (Alvaro Herrera) writes:
On Tue, Aug 30, 2005 at 12:45:18PM -0400, Chris Browne wrote:
[EMAIL PROTECTED] (David Parker) writes:
The slony log trigger saves execution plans, so any given
connection that has been used with a slony schema installed will
have cached OIDs
Simon Riggs wrote:
The summary was:
1. Have a PCTFREE column added on a table by table basis
I think a good place to keep PCTFREE value is a new column
in the pg_class, and ALTER TABLE should be able to change this value.
2. Apply PCTFREE for Inserts only
3. Allow Updates to use the full
Tom Lane wrote:
Rocco Altier [EMAIL PROTECTED] writes:
Also, kookaburra (AIX) has a problem with the stats test as well.
kookaburra's problem is entirely different, not intermittent in the
least. The error diff shows that stats collection is off, and its
postmaster log says
LOG:
8.1-beta1 produces some odd results with statement logging enabled when
the extended query protocol is used (e.g. when using the JDBC driver).
Repeatedly running a simple query with log_statement = 'all' produces this:
LOG: statement: PREPARE AS SELECT 'dummy statement'
LOG: statement: BIND
37 matches
Mail list logo
