3 ms·
Are you being deliberately obtuse? You're the one being obtuse here. I introduced four databases, three of which use more complex replication models than PG,
by moe 12y ago
Are you being deliberately obtuse?
You're the one being obtuse here.
I introduced four databases, three of which use more complex replication models than PG, all of which are easier to admin than PG. And I'm asking PG to make their (simpler) replication as easy to use as these other databases.
If that's too confusing then just use Redis for reference and ignore the other three. Redis is plain master/slave and spinning up a slave takes a single command ("SLAVEOF foo"). That's exactly how it should be in postgresql as well. Not more, not less.
- lobster_johnson 12y agoThey can and do use different replication models because their data model is explicitly wildly different from Postgres. For example, Postgres couldn't support eventual consistency even if it wanted to. You're barking up the wrong tree. As for Redis, sure, it has a simple master/slave system and Postgres could offer a similarly simple command UI that would let you issue a command instead of doing the current, trivial amount of setup. I don't disagree, but I think it's an inconsequential problem that affects a sysadmin/devops person about five minutes each year, and an issue that ultimately only deters dilettantes. The real problem to solve is dynamic promotion/demotion of masters and slave. It's not entirely trivial [1]. [1] http://redis.io/topics/sentinel http://redis.io/topics/sentinel
- moe 12y agoPostgres couldn't support eventual consistency even if it wanted to. You're barking up the wrong tree. And you're barking at a strawman. Nobody was talking about eventual consistency. I don't disagree You could do that less verbosely then. The real problem to solve is dynamic promotion/demotion of masters This whole thread is about how postgres hasn't even streamlined the manual promotion/demotion of one master in a simple master/slave pairing.