mason_s

4 ms·

1.
by mason_s 12y ago
Failovers are currently handled outside of Postgres-XL. Consistency is achieved because all of the nodes use the same transaction ids and snapshots (list of running transactions), via the Global Transaction Manager. There is no need to worr
2.
by mason_s 12y ago
Postgres-R bits have not made their way into Postgres-XL, but some parts of Postgres-XC have. Some XC code is merged in to make future merging into Postgres-XL easier, even parts that are not used. Some parts of Postgres-R are in the TransL
3.
by mason_s 12y ago
The planner and executor in Postgres-XL is quite different, and direct node-to-node data transfer for MPP parallelism results in big performance gains. Any bugs in XC in the planner and executor would not show up in XL (that is not to say t
4.
by mason_s 12y ago
It is possible to configure a GTM Standby on another node to take over for GTM. It currently requires manual failover, however.
5.
by mason_s 12y ago
Well, "synchronous replication" is used in a couple of ways here. Tables can be designated as replicated or distributed (sharded). Replicated tables are typically fairly static. These are handled synchronously in the cluster on ev
6.
by mason_s 12y ago
Nothing wrong with staying that at all. It is easier to get started with. We should try to create some AMI images to make it a little easier to get up and running at AWS with Postgres-XL.
7.
by mason_s 12y ago
Yes, but ensure that you have backups, and possibly a warm standby. Postgres-XL is hopefully at least reassuring that once those scaling problems do crop up, there is something available that can help.
8.
by mason_s 12y ago
It may be that coordinators and datanodes, while the same binary, become one and the same as the same process. At the moment that is not the case. The Global Transaction Manager here ensures that transaction ids and snapshots (the context i
9.
by mason_s 12y ago
I would think of it more as a branch. A big branch. The intent is to always merge in upstream from PostgreSQL. Anyway, you do not run on top of it, changes have been made deep in the bowels of PostgreSQL.
10.
by mason_s 12y ago
Because they are not good at diagrams? Just emphasizing the key components of the architecture.