Re: Postgres UPGRADE from 9.2 to 9.4 - Mailing list pgsql-general

From Patrick B
Subject Re: Postgres UPGRADE from 9.2 to 9.4
Date
Msg-id CAJNY3isKSN75-PTEbB7x-joxJXs01Dc+nmsYi+5PWw4Gsdq1Tw@mail.gmail.com
Whole thread Raw
In response to Re: Postgres UPGRADE from 9.2 to 9.4  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-general


2016-09-09 1:09 GMT+12:00 Scott Marlowe <scott.marlowe@gmail.com>:
On Tue, Sep 6, 2016 at 5:25 PM, John R Pierce <pierce@hogranch.com> wrote:
> On 9/6/2016 4:20 PM, Melvin Davidson wrote:
>>
>> If you use slony to replicate, you CAN have 9.2 on the master and 9.4 on
>> the slave.
>
>
> does rackspace support slony?  how about amazon dms ?
>
> slony requires configuring replication on each table.  if the database has a
> large complex schema this could take considerable setup effort.
>

Not really. As of slony 2.2 you can use a regular expression to add
tables or sequences.

i.e.:

SET ADD TABLE (
    SET ID=1,
    TABLES='public\\.*'
);

repeat for sequences.  Two commands. I don't consider that considerable effort.
--
To understand recursion, one must first understand recursion.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


https://wiki.postgresql.org/wiki/Slony

The main drawback to Slony-I even as a replication system is the complexity of its setup and administration. The design of the system, with the database itself being used for queueing row updates, also significantly increases the amount of data writing and I/O done by the DBMS.

Also, since Slony-I is asynchronous master-slave, all writes have to be segregated to the master. Additionally, there is a noticeable lag (1-3 seconds) between the master and the slaves which may cause users to have an inconsistent view of the data.



So, Slony won't be used by us. 

pgsql-general by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: SERIALIZABLE and INSERTs with multiple VALUES
Next
From: avi Singh
Date:
Subject: Re: MultiXact member wraparound protections are disabled