On 13 November 2012 13:05, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Simon Riggs escribió: > >> > So even if this solution doesn't meet all requirements of single >> > process solution (and neither I think it is written to address all) >> > but can't we think of it as first version and then based on >> > requirements extend it to have other capabilities: >> > a. to have a mechnism for other background processes (autovacuum, >> > checkpoint, ..). >> > b. more needs to be thought of.. >> >> Why would we spend time trying to put back something that is already >> there? Why not simply avoid removing it in the first place? > > Actually, the whole point of this solution originally was just to serve > pg_upgrade needs, so that it doesn't have to start a complete postmaster > environment just to have to turn off most of what postmaster does, and > with enough protections to disallow everyone else from connecting.
I don't see anything that pg_upgrade is doing that causes the need to support a special mode. From other people's comments it's clear that "single user mode" is desirable to many and *will* be widely deployed if we allow it. I support the wish to allow a database server to be limited by configuration to a single user. However, supporting a specifically targeted mode that presents single user as an architectural design/limitation is a regressive step that I am strongly opposed to. The most popular relational database in the world is Microsoft Access, not MySQL. Access appears desirable because it allows a single user to create and use a database (which is very good). But all business databases have a requirement for at least one of: high availability, multi-user access or downstream processing in other parts of the business. Businesses worldwide curse the difficulties caused by having critical business data in desktop databases. And worldwide, there are also many that don't understand the problems that disconnected data causes because they can't see past the initial benefit. The lessons from that are that its OK to start with a database used by a single person, but that database soon needs to allow access from multiple users or automated agents. Many database systems support embedded or single user mode as an architectural option. All of those systems cause headaches in all of the businesses where they are used. They also cause problems on small detached devices such as phones, because even on very small systems there is a requirement for multiple concurrently active processes each of which may need database access. PostgreSQL was designed from the ground up as a multi-user database. This is the very fact that puts us in a good position to become pervasive. A single database system that works the same on all devices, with useful replication to connect data together. The embedded or single mode concept has long been on the "do not want" list. I believe that is a completely rational and strongly desirable thing. Supporting multiple architectures is extra work, and the restrictive architecture bites people in the long term. The fact that its an "easy patch" is not a great argument for changing that position, and in fact, its not easy, since it comes with a request to make it work on Windows (= extra work). The "easy" bit is not proven since people are already starting to ask about bgwriter and autovacuum. In this release there is much work happening around providing additional autonomous agents (bgworker) and other work around flexible replication (BDR), all of which would be nullified by the introduction and eventual wide usage of a restrictive new architecture. Single user configuration option, yes. Architecturally limited special version of PostgreSQL, no. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers