Philippe Amelant wrote:
I'm setting up a 3 nodes cluster and after some tests
I just discover that the cascading slave does not recover.
Right, switching timeline over streaming replication
is not supported yet. There's a patch by Heikki in
the pipeline for this, so it will probably work in
Pawel Veselov wrote:
QUESTION: If multiple pgpools are running, and if there are no network
problems,
and configuration
files are identical, is there any guarantee that the same stand-by node
will be selected for
promotion? Concern here is that with configuration of (M-SB0-SB1) one
Pawel Veselov wrote:
From your later comments, it's also apparent that these archived WALs will
be useless after
failover (for the purpose of recovery), so there is no reason to send them
to all the nodes after all.
I obviously lost it here. The archives do need to be synchronized, for
Hello,
Thank for all this informations
Le 13/11/2012 09:31, Albe Laurenz a écrit :
Philippe Amelant wrote:
I'm setting up a 3 nodes cluster and after some tests
I just discover that the cascading slave does not recover.
Right, switching timeline over streaming replication
is not supported
Hi!
I've found an old thread on OpenVZ:
(2008): http://archives.postgresql.org/pgsql-performance/2008-03/msg00076.php
And a more recent question that scared me a bit:
(2011): http://serverfault.com/questions/281783/running-mongodb-with-openvz
On the PostgreSQL general mailing list, I've only
Philippe Amelant wrote:
I'm setting up a 3 nodes cluster and after some tests
I just discover that the cascading slave does not recover.
Right, switching timeline over streaming replication
is not supported yet. There's a patch by Heikki in
the pipeline for this, so it will probably work in
On Fri, Nov 9, 2012 at 2:50 PM, Eliot Gable
egable+pgsql-gene...@gmail.com wrote:
one thing that can cause this unfortunately is advisory locks eating
up exactly the amount of shared memory you have. that's another thing
to rule out.
How would I rule this out?
It really was filling the
Greg Williamson wrote:
running transactions can cause autovacuum processes to stall
out or be autocancelled. Long running transactions - is now
long? In our system it's rare to have a transaction (even a
prepared transaction) last much longer than a few minutes. Is
that enough time to cause
Hello Guys;
Today, I have noticed that my dumps are not working due to bad practice in
writing SQL queries.
In the past, I there was a scenario where I there are two tables, one of them
is completely dependent on the other. i.e. the foreign key and the primary
key constraint assigned
On Tue, Nov 13, 2012 at 2:53 PM, François Beausoleil
franc...@teksol.info wrote:
Hi!
I've found an old thread on OpenVZ:
(2008): http://archives.postgresql.org/pgsql-performance/2008-03/msg00076.php
And a more recent question that scared me a bit:
(2011):
Dear listmembers,
I need to move
/var/lib/postgresql/8.4/main
from the / partion to another disc.
Based on the
http://wiki.postgresql.org/wiki/Simple_Configuration_Recommendation#File_System_Layouts
I plan the following.
0.) Mount new pgroot, are there any hints for the mount command?
Le 13/11/2012 14:57, Albe Laurenz a écrit :
Philippe Amelant wrote:
So i was thinking it was just a reconnect to the sender (and I can see
the standby trying to reconnect in the log)
Hmmm. I think I was too quick when I said no.
If you ship the WAL archives including the history file to
Hi all,
Recently, during a performance improvement sweep for an application at my
company, one of the hotspots that was discovered was pagination.
In order to display the correct pagination links on the page, the
pagination library we used (most pagination libraries for that matter) ran
the
On Mon, Nov 12, 2012 at 12:04 PM, Lists li...@benjamindsmith.com wrote:
Should I increase the max_workers field from the default of 3 to (perhaps)
10?
I would not. You report that the reason you turned off autovac is
because it made your database crawl when it kicked in. That suggests
that
Carlos Henrique Reimer carlos.rei...@opendb.com.br writes:
That is what I got from gdb:
ExecutorState: 11586756656 total in 1391 blocks; 4938408 free (6
chunks); 11581818248 used
So, query-lifespan memory leak. After poking at this for a bit, I think
the problem has nothing to do with
Is there a trick to using window functions to SET columns in an UPDATE?
Here is the query I'd like to run:
UPDATE profiles
SET score_tier = percent_rank()
OVER (PARTITION BY site_id ORDER BY score ASC)
WHERE score IS NOT NULL
But that gives me
On 11/13/2012 11:26 PM, Aleksandar Lazic wrote:
Dear listmembers,
I need to move
/var/lib/postgresql/8.4/main
from the / partion to another disc.
If so, you're probably using `pg_wrapper` for cluster management.
Confirm that with `pg_lsclusters`. If the command exists and it shows an
8.4
Hi,
I'm wondering which type of SSDs would be better for use with PostgreSQL.
Background:
At the moment, SSD drives fall into two categories..
Those that use internal-compression on the SandForce controller, which
gives very fast speeds for compressible data; and those that don't.
In
18 matches
Mail list logo
