- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
You must log in or register to comment.
If they feel that they would have to support process model even after migration to threaded one, I think the change should be done in a fork. Less maintenance and problems with backward compatibility, and hopefully with time the new approach will get enough traction to turn off the lights in the old one.
It strikes me that this is the sort of situation where developers interested in this architectural change should fork Postgress to a new project instead of redirecting the development of Postgress altogether.
where developers interested in this architectural change
According to the article, no one really disagreed with it at a high level. Obviously the details of how to get there are going to be relatively complicated and different people will probably have different ideas about the best approach to use.
should fork Postgress to a new project instead of redirecting the development of Postgress altogether.
Did you read the article? Basically the point is the world has moved on and the existing approach is outdated and starting to show its age and limitations.
Forking and making a new project is basically saying Postgres is obsolete and will stay obsolete. Assuming people can generally agree that changes are needed to stay relevant, updating the existing project to keep up with the times seems like a better approach to me.
It’s the same way a lot of web servers (and just daemons in general) used to use a forking model but eventually either died or transitioned to using IO multiplexing. The fork based approach just became obsolete, and projects had to adapt or get replaced.
