Replication support has been a big issue with Postgres in the past, with folks needing third party proxies that were clumsy to use to accomplish it. This improvement is big news.
It sounds like there are a lot of improvements with this release of Postgres, and that they are taking a less conservative approach to development than they have in the past; I hope that they won't sacrificed stability too much to accomplish this.
I'm not sure what you base the less conservative approach to development comment on. As far as I know, the development process and patch application process is the same as it has been in recent years. Stability and quality of code are still #1.
Edit: clarified the conservative approach to development.
Perhaps the submission itself? From the first paragraph:
"While past major releases have been quite conservative in their scope, this release shows a bold new desire to provide facilities that every new and existing user of PostgreSQL will embrace."
I think you misunderstand me I don't mean to imply that the Postgres developers have decided to be sloppier in their development practices or anything like that. When I say 'less conservative in development' I mean that scope is an aspect of development. When a project's scope increases, so does it's workload and complexity; a development team can either allocate more resources and time to the project or let quality slide. This is a truism and I mean no slight to the Postgres people who, in my experience have consistently delivered a very stable project to date and may very well be able to handle a broader scope with no loss in quality.
If I had one feature wish free, it would be the option of having an option to sort by multiple locale specific sorting orders in the same database.
Earlier, this was specified at cluster initialization time (initdb), then it was one a database level (create database), but what I would really like to see is being able to specify it on query time or, failing that, I would at least like to be able to create multiple indexes with different locales and use those to sort the data.
In the application in question I have to do all sorting on the client side now which also means that pagination needs to be done on the client side which is a huge networking overhead between database and application as I'm fetching rows, sorting them and then throwing away the majority of them.
Aside of that, I love, love, love PostgreSQL ever since I switched from MySQL back in 2000. Every new release was such a pleasure to try out and every time I was happily integrating all newly gained features in my applications.
Is the build in replication support able to correctly replicate schema changes to the slaves? That was the biggest issue with the existing solutions for most admins I talked to.
It's based on shipping write-ahead-logs around, so anything you can do inside a transaction (pretty much any DML or DDL statements except for ones that affect the entire cluster, like "CREATE USER" or "DROP DATABASE") can be replicated.
As with any major postgres update this calls from a full dump of the database and a restore into the new version-you can't simply update the database files.
pg_dump -clean makes this a snap so you shouldn't have any problems upgrading. (oh and if you're doing backups-you are using pg_dump --clean right? Its really the best way).
maybe we'll get an updated pg_migrator once the release is out. While dump/restore is for sure the safer option, once your databases reach Terabytes in size, doing the migration in-place (most of the time the on-disc structure is quite similar between releases) will be a huge speed advantage.
Nice. Say goodbye to Slony? I am downloading the beta right now for play use. I would like an easier AWS setup with two EC2s running replicated PostgreSQL.
There's no "marketing" direction; the project is not trying to capitalize on anything. It's adding requested features when they're stable and able to be implemented in a way that has consensus among the committers.
No I think they are just responding to user demand, as the first sentence in the notes states:
Based on overwhelming user demand, this release of PostgreSQL adds features that have been requested for years, like easy-to-use replication, a mass permission facility, and anonymous blocks.
I'd say the project has been more interested in making its own space than targeting users of any particular product. Now if you take companies like EnterpriseDB, they are specifically targeting Oracle users. That, however, is entirely independent of the project itself.
It sounds like there are a lot of improvements with this release of Postgres, and that they are taking a less conservative approach to development than they have in the past; I hope that they won't sacrificed stability too much to accomplish this.