with
given backend PID so it seemed to me as it's problem during backend
startup - we have log_connections to on...
Thanks,
Kuba
Dne 9.11.2010 2:04, Tom Lane napsal(a):
I looked into the out-of-memory problem reported by Jakub Ouhrabka here:
http://archives.postgresql.org/pgsql-general/2010-11
is that there is no database activity (queries,
connections) and stats collector is still eating CPU.
Kuba
Dne 16.2.2010 8:29, Greg Smith napsal(a):
Jakub Ouhrabka wrote:
I've found similar reports but with older versions of postgres:
http://old.nabble.com/100--of-CPU-utilization-postgres-process
for the quick answer and precise answers.
PostgreSQL is really unique in this regard!
Kuba
Dne 16.2.2010 15:10, Alvaro Herrera napsal(a):
Jakub Ouhrabka wrote:
You might want to try setting log_autovacuum_min_duration=0 in the
postgresql.conf
Thanks, tried it. There is nothing in the log - the actual
I
reading the code correctly? If so then 1s is not enough for big clusters.
I guess it would be feasible to crank STATS_READ_DELAY up a little bit,
say to 10s. What do you think?
Kuba
Dne 16.2.2010 19:59, Alvaro Herrera napsal(a):
Jakub Ouhrabka wrote:
Maybe you should decrease naptime
the stats file on ramdisk.
Kuba
Dne 17.2.2010 0:12, Alvaro Herrera napsal(a):
Tom Lane wrote:
Alvaro Herreraalvhe...@commandprompt.com writes:
Jakub Ouhrabka wrote:
Was autovacuum requesting to write this 20MB file 650x per minute?
Yes, exactly.
Ideally, autovacuum would only request
This would guarantee that autovacuum is fired no later than
autovacuum_naptime after the condition for the run became true.
Of course, this unfortunately not true... The guarantee is 1,5x
autovacuum_naptime. But I'd be happy with it but I agree that's not what
I'd as a user expect from this
Hi,
sorry for repost but previous message didn't get through. So I'm trying
another list and sending without attachment which I can send privately
upon request (strace output mentioned below).
We've migrated some of our databases to 8.4 cluster (from 8.2 and older
versions).
These
and templates
4) start the database
5) create all text/varchar user indexes
Sounds this about right? I'd like to minimize downtime...
How to do step 2) - change the locale??
Thanks a lot,
Kuba
Martijn van Oosterhout napsal(a):
On Mon, Feb 19, 2007 at 09:27:06AM +0100, Jakub Ouhrabka wrote:
But I
Hi,
we've made mistake and initdb database cluster in wrong locale :-(
Now it's full of data. I've read in the docs that it's not possible to
change locale.
But I guess something like this would work:
a)
1) drop all indexes on text/varchar columns
2) change cluster locale
3) create all
Hi Tom,
Hacking pg_control would be the hard part; you'll never get the CRC
right if you do it manually. Possibly pg_resetxlog could be adapted
to the purpose.
thanks for your valuable answer! I looked at pg_resetxlog.c but I'm no
pg internals' expert - would something like this work?
1)
Hi,
I use it and can recommend it. It is actively developed/maintained (the
updates are free). There is very basic support of 7.3 schemas in the
new version for instance... And the development team is very responsive,
if you don't like or missing something write them...
kuba
On Sun, 2 Feb 2003
hi,
i think that ecpg is only text preprocessor. it doesn't understand the c
semantics - it goes from the top to the end of the file row by row and
sees your declaration twice.
kuba
On Tue, 12 Nov 2002, Marc G. Fournier wrote:
if (ic_flag == 1) {
/*only select those
hi,
can anyone explain me why there are different query plans for select ...
from ... where y!=x and select ... from ... where yx or yx for
integers, please?
see the details below...
thanks,
kuba
db_cen7=# analyze;
ANALYZE
db_cen7=# \d ts19
Table ts19
13 matches
Mail list logo
