On Sat, Feb 27, 2016 at 1:49 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: > pg_tsdtm is based on another approach: it is using system time as CSN and > doesn't require arbiter. In theory there is no limit for scalability. But > differences in system time and necessity to use more rounds of communication > have negative impact on performance.
How do you prevent clock skew from causing serialization anomalies? > So there is no ideal solution which can work well for all cluster. This is > why it is not possible to develop just one GTM, propose it as a patch for > review and then (hopefully) commit it in Postgres core. IMHO it will never > happen. And I do not think that it is actually needed. What we need is a way > to be able to create own transaction managers as Postgres extension not > affecting its core. This seems rather defeatist. If the code is good and reliable, why should it not be committed to core? > All arguments against XTM can be applied to any other extension API in > Postgres, for example FDW. > Is it general enough? There are many useful operations which currently are > not handled by this API. For example performing aggregation and grouping at > foreign server side. But still it is very useful and flexible mechanism, > allowing to implement many wonderful things. That is true. And everybody is entitled to an opinion on each new proposed hook, as to whether that hook is general or not. We have both accepted and rejected proposed hooks in the past. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
