Any assistance available on this topic?
-- Forwarded message --
From: Selva manickaraja
Date: Thu, Feb 17, 2011 at 10:10 AM
Subject: Trigger File Behaviour
To: pgsql-admin@postgresql.org
Hi,
We tried setting the trigger file for fail-over purpose. But we just can't
understand h
Hi,
We tried setting the trigger file for fail-over purpose. But we just can't
understand how it works. Each time the secondary is started the trigger file
is removed. How can we introduce auto fail-over is this happens?
Thank you.
Regards,
Selvam
(Added list back to keep me honest :-)
On Wed, Feb 16, 2011 at 8:41 PM, Selva manickaraja wrote:
> So what would be the best option for there on? Should the standby be
> converted to primary and the initial primary now nominated as standby?
Once you convert to a primary, you're stuck on it. Yo
On Wed, Feb 16, 2011 at 8:29 PM, Selva manickaraja wrote:
> Dear All,
>
> We have a primary running continous archiving to a secondary. We managed to
> test fail-over to the secondary by stopping the database in the primary.
> Then some transactions were tested in the secondary. It was acting well
Dear All,
We have a primary running continous archiving to a secondary. We managed to
test fail-over to the secondary by stopping the database in the primary.
Then some transactions were tested in the secondary. It was acting well as a
primary to accept both read and write.
Now we want to revert
Bernhard Schrader wrote:
> Doesn't anyone know if I could override this settings?
> LC_COLLATE should be interesting for sort order, and while both is utf8,
> it should work or am I totally wrong?
>
> As far as I read right now, LC_COLLATE is a read_only variable which is
> used while initdb. But
On Wed, 2011-02-16 at 15:56 -0500, Greg Smith wrote:
> Bryan Keller wrote:
> > It sounds like NFS is a viable solution nowadays. I a still going to shoot
> > for using iSCSI, given it is a block-level protocol rather than file-level,
> > it seems to me it would be better suited to database I/O.
>
Bryan Keller wrote:
It sounds like NFS is a viable solution nowadays. I a still going to shoot for
using iSCSI, given it is a block-level protocol rather than file-level, it
seems to me it would be better suited to database I/O.
Please digest carefully where Joe Conway pointed out that it
Bryan Keller wrote:
> I am considering running a Postgres with the database hosted on a NAS
> via NFS. I have read a few things on the Web saying this is not
> recommended, as it will be slow and could potentially cause data
> corruption.
>
> My goal is to have the database on a shared filesystem
On Wed, Feb 16, 2011 at 1:33 PM, Scott Marlowe wrote:
> On Wed, Feb 16, 2011 at 12:45 PM, Armin Resch wrote:
>> Hi there,
>>
>> what options do exist to replicate from a master by schema?
>>
>> What I'm really after is this scenario:
>>
>> Say, I have 100 databases out in the field. All of them h
On Wed, Feb 16, 2011 at 12:45 PM, Armin Resch wrote:
> Hi there,
>
> what options do exist to replicate from a master by schema?
>
> What I'm really after is this scenario:
>
> Say, I have 100 databases out in the field. All of them have the same schema
> and are autonomous masters. Now, at a cent
Hi there,
what options do exist to replicate from a master by schema?
What I'm really after is this scenario:
Say, I have 100 databases out in the field. All of them have the same schema
and are autonomous masters. Now, at a central location, I want to replicate
from all masters to a central sla
On 2011-02-16 04:51, Greg Smith wrote:
Debian and Ubuntu installations have a unique feature where you can
have multiple PostgreSQL installations installed at the same time.
That's pretty easy to do with any Linux distribution.
--
Mail to my list address MUST be sent via the mailing list.
A
On ons, 2011-02-16 at 13:14 +0100, Bernhard Schrader wrote:
> If i reinitialize the database cluster, won't i have to pg_dump restore
> my data? In this case the downtime would be to big. Therefore I'm
> searching for a faster way.
I said reinitialize your new database cluster. Since you're runn
Sairam Krishnamurthy wrote:
I am using Ubuntu 10.04 and Postgres 8.4, I have been trying to move
my data dir to another device for the past couple of days but ran into
a lot of problems.
I did the following:
1. Copy the contents of /var/lib/postgresql/8.4/main to my folder.
2. Changed the data_
If i reinitialize the database cluster, won't i have to pg_dump restore
my data? In this case the downtime would be to big. Therefore I'm
searching for a faster way.
utf8 and UTF-8, should be the same in my opinion, so i think there must
be a way to just change this value, so that pg_upgrade can
On mån, 2011-02-14 at 14:18 +0100, Bernhard Schrader wrote:
> As far as I read right now, LC_COLLATE is a read_only variable which
> is used while initdb. But why does the pg_upgrade script doesn't see
> that utf8 and UTF-8 are the same? Is it just a string compare?
Why don't you just reinitializ
Στις Wednesday 16 February 2011 00:00:10 ο/η Jan-Peter Seifert έγραψε:
> Hello,
>
> Am 15.02.2011 12:26, schrieb Achilleas Mantzios:
> > Στις Tuesday 15 February 2011 12:44:31 ο/η Lukasz Brodziak έγραψε:
> >> Hello,
> >>
> >> How can I set PostgreSQL locale and encoding to be pl_PL.cp1250 all I
>
18 matches
Mail list logo
