<story><title>Postgres 9.5 feature highlight: row-level security and policies</title><url>http://michael.otacoo.com/postgresql-2/postgres-9-5-feature-highlight-row-level-security/</url></story><parent_chain><item><author>syntern</author><text>I open every &amp;quot;New Postgresql features&amp;quot; article in the hope that it will contain &amp;quot;Simple cluster setup, you just start nodes and they will figure out the rest.&amp;quot; Unfortunately it didn&amp;#x27;t happen so far...&lt;p&gt;Is it such a hard problem, that no one is able to solve it, or it is not a concern or interest of the parties that are developing Postgresql or the tools around it?&lt;p&gt;(And by hard problem, I don&amp;#x27;t mean surviving an aphyr-level diagnostics without any issues, but it it would be certainly nice to see such too.)&lt;p&gt;Edit: I&amp;#x27;d settle for a multi-master replicated cluster, where the node failures and startups (and the migration of the data) is handled transparently in the cluster. I know that there are many other aspects, but even this basic case is painfully hard to achieve (much harder than with MySQL).</text></item></parent_chain><comment><author>saosebastiao</author><text>It probably will never happen. Postgres follows an ideology of explicit and safe...it never tries to assume that you meant to do one thing if there is a possibility that you meant another.&lt;p&gt;With clusters, there are far too many variables for it to be plug and play. For example, do you want replication, or distributed partitions? If replication, do you want master-slave, or master-master? If distributed partitions, what are you going to trade off: consistency or availability? (That being said, Postgres will likely never change from its CA stance, you&amp;#x27;ll have to use an alternative distribution like PostgresXL).&lt;p&gt;Furthermore, clustering isn&amp;#x27;t likely to be much more than a pareto-tail problem for the next decade or so. It is useful for millions of use cases, and something that only Google&amp;#x27;s and Twitter&amp;#x27;s can benefit from is not one of them. If you have the data to justify extensive clustering requirements, I would hope you also have the resources to contribute your patches to Postgres. So far, they all seem to be content solving their own niche problems with niche solutions that slowly bleed down to us mere mortals (Ex. Cassandra), or just buying a solution like EnterpriseDB or Oracle.</text></comment>
<story><title>Postgres 9.5 feature highlight: row-level security and policies</title><url>http://michael.otacoo.com/postgresql-2/postgres-9-5-feature-highlight-row-level-security/</url></story><parent_chain><item><author>syntern</author><text>I open every &amp;quot;New Postgresql features&amp;quot; article in the hope that it will contain &amp;quot;Simple cluster setup, you just start nodes and they will figure out the rest.&amp;quot; Unfortunately it didn&amp;#x27;t happen so far...&lt;p&gt;Is it such a hard problem, that no one is able to solve it, or it is not a concern or interest of the parties that are developing Postgresql or the tools around it?&lt;p&gt;(And by hard problem, I don&amp;#x27;t mean surviving an aphyr-level diagnostics without any issues, but it it would be certainly nice to see such too.)&lt;p&gt;Edit: I&amp;#x27;d settle for a multi-master replicated cluster, where the node failures and startups (and the migration of the data) is handled transparently in the cluster. I know that there are many other aspects, but even this basic case is painfully hard to achieve (much harder than with MySQL).</text></item></parent_chain><comment><author>JonnieCache</author><text>It&amp;#x27;s a hard problem, and the Postgres team&amp;#x27;s careful approach to engineering means that they are solving it slowly, in comparison to the current fashion for ship first, patch later.&lt;p&gt;They bring stuff in piece by piece, eg. in 9.4 they added logical changeset extraction&amp;#x2F;logical log streaming replication, which is another step down the road to clustering. On top of this they are building bi-directional replication. And so it continues.&lt;p&gt;This is the same reason they haven&amp;#x27;t added upsert or merge yet.</text></comment>