Le 11/02/2011 05:43, Selva manickaraja a écrit :
> We are considering on using a primary and 2 secondary machines. But our plan
> is to cascade the recovery as follows:
>
> 1. Primary Machine-A (read and write operation)
> 2. Secondary Machine-B (recover from Machine A)
> 3. Secondary Machine-C (r
We are considering on using a primary and 2 secondary machines. But our plan
is to cascade the recovery as follows:
1. Primary Machine-A (read and write operation)
2. Secondary Machine-B (recover from Machine A)
3. Secondary Machine-C (recover from Machine B)
We are planning this kind of recovery
create table tmp
(
id serial not null primary key,
name text,
age integer
);
insert into tmp (name,age) values ('keith', 43),('leslie', 40),('bexley',
19),('casey', 6);
update tmp
set age = data_table.age
from
(
select 'keith'::text as name, 44::integer as age
union
select 'leslie', 5
Hi...
If i can't upgrade a server with postgres 8.1 and at this time i can't delete a
super user, Is there any way to avoid that the super user mapping libraries in
C code? like system y libc.so ?
regards...
I am using Postgresql 9.0 with its native replication and continous
archiving. As per my understanding the primary and secondary communication
via log files for continous archiving and direct postgres engine to engine
communication for replication. These should not be a problem since I can use
the
On 02/09/2011 03:49 PM, Jim Mlodgenski wrote:
On Wed, Feb 9, 2011 at 2:59 PM, 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 d
Hi all,
I just tried to pg_upgrade a PostgreSQL-8.4 to 9.0.
pg_upgrade stopped with this message:
"old and new cluster lc_collate values do not match"
So i checked the LC_COLLATE on 8.4 and 9.0:
8.4:
postgres=# show lc_collate;
lc_collate
en_US.utf8
(1 row)
9.0:
postgres=# show
Hi,
Il 09/02/11 17:53, CS DBA ha scritto:
One of the main considerations per Hot Standby vs SLONY is replication
scope. With Hot Standby you get everything that occurs in the cluster,
across all databases.
Yep, I agree with you Kevin regarding the replication scope. I assumed
that Jai was loo
Hello,
I'd like to check how reasonable our Fillfactors settings are (for
indexes),
but I'm not sure which statistics can be used for this.
best regards,
Marc Mamin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
Thanks, Norbert!
I'll run the perl 5.10 upgrade past the guys.
Sam
On Thu, Feb 10, 2011 at 6:27 PM, Norbert Zacharias
wrote:
> Moin,
>
>> Howdy,
>>
>> Environment:
>>
>> Postgres 8.3.13
>> Solaris 10
>>
>> I have a SELECT query that runs no problem standalone but when running
>> within a perl
On Thu, 2011-02-10 at 16:39 +0800, Selva manickaraja wrote:
> We are in the process of setting up
> (a) Continous Archiving between machineA and machine B (Both Linux)
> (b) Replication between machineA and machineC (Both Linux)
> (c) Continous Archiving between machineA and machineD (Linux and
> W
Hi,
We are in the process of setting up
(a) Continous Archiving between machineA and machine B (Both Linux)
(b) Replication between machineA and machineC (Both Linux)
(c) Continous Archiving between machineA and machineD (Linux and Windows)
We got the (a) and (b) working and are in trial mode. We
Moin,
> Howdy,
>
> Environment:
>
> Postgres 8.3.13
> Solaris 10
>
> I have a SELECT query that runs no problem standalone but when running
> within a perl script it intermittently core dumps. Random, no pattern
> to the timing of the core dumps. The perl script processes the rows
> from the que
13 matches
Mail list logo
