On Mon, Nov 10, 2014 at 9:02 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> +1. Adding columns is a PITA, you have to manually ensure you do it on all
> slaves first.
>
> Drop is somewhat worse, because you have to do it on the master first,
> opposite of the (more usual) case of adding a column.
>
> RENAME is a complete disaster.
>
> Handing scripts to your replication system to execute isn't a very good
> alternative either; it assumes that you actually have a script (bad
> assumption with ORMs), and that you have a reasonable way to get that script
> to wherever you run your replication system.
I don't disagree with any of that, but running the command on the
master and then propagating it to the slaves where it may succeed or
fail - and if it fails, you won't know unless you're watching the logs
on those machines, and, oh by the way, replication will also be broken
- is not good either. We would never have shipped physical
replication solution with that kind of limitation. What has made
streaming replication so popular and successful with PostgreSQL users
over the last five years is that, while it's a bit of a pain to get
set up, once you have it set up, it is rock-solid. If there were a
series of legal SQL commands that you could execute without error on a
cluster of servers connected by streaming replication such that, when
you got done, replication was broken, our users would scream bloody
murder, or just stop using PostgreSQL. I think the approach to DDL
replication that Alvaro, Andres, et al. are proposing here is
absolutely fine - even praiseworthy - as an out-of-core solution that
users can adopt if they are willing to accept the associated risks, as
many users probably will be. But you wouldn't convince me to run it
on any production system for which I was responsible.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
