4 ms·

Hinted handoff multimaster What does multi-master have to do with anything? The subject was making the postgres master/slave replication as easy to use as the

by moe 12y ago

Hinted handoff multimaster What does multi-master have to do with anything? The subject was making the postgres master/slave replication as easy to use as the aforementioned db's. Yes, some of them use more advanced clustering models (multi-master) than postgres and are still easier to use. That doesn't exactly make postgres look better in the comparison.

lobster_johnson 12y ago
Are you being deliberately obtuse? You explicitly mentioned four multimaster key/value stores: Rethinkdb, Redis, Riak, ElasticSearch all do. (them not being relational is irrelevant to replication) I argued that those are not RDBMSes, and that their replication model was much simpler, something you still seem to be arguing against. I don't disagree that Postgres's replication could be much nicer, but you're not articulating your position well. For one, bringing up these completely apples-to-orange comparisons makes no sense.
- 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 ago
    They 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 ago
      Postgres 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.

by moe 12y ago

lobster_johnson 12y ago

Are you being deliberately obtuse? You explicitly mentioned four multimaster key/value stores: Rethinkdb, Redis, Riak, ElasticSearch all do. (them not being relational is irrelevant to replication) I argued that those are not RDBMSes, and that their replication model was much simpler, something you still seem to be arguing against. I don't disagree that Postgres's replication could be much nicer, but you're not articulating your position well. For one, bringing up these completely apples-to-orange comparisons makes no sense.

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 ago
  They 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 ago
    Postgres 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.