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.…
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…
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…
It is possible to configure a GTM Standby on another node to take over for GTM. It currently requires manual failover, however.
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…
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.
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.
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…
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.
Because they are not good at diagrams? Just emphasizing the key components of the architecture.
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.…
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…
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…
It is possible to configure a GTM Standby on another node to take over for GTM. It currently requires manual failover, however.
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…
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.
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.
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…
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.
Because they are not good at diagrams? Just emphasizing the key components of the architecture.