Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers
From | Simon Riggs |
---|---|
Subject | Re: Proof of concept: standalone backend with full FE/BE protocol |
Date | |
Msg-id | CA+U5nMKC16xyFa5tSS8X0Fsgr1VtZ=s-QKLmxQAmfeuriGsE5g@mail.gmail.com Whole thread Raw |
In response to | Re: Proof of concept: standalone backend with full FE/BE protocol (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Proof of concept: standalone backend with full FE/BE protocol
Re: Proof of concept: standalone backend with full FE/BE protocol |
List | pgsql-hackers |
On 13 November 2012 17:38, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndquadrant.com> writes: >> 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. > > That's a mighty sweeping claim, which you haven't offered adequate > evidence for. The fact of the matter is that there is *lots* of demand > for simple single-user databases, and what I'm proposing is at least a > first step towards getting there. I agree there is lots of demand for simple single-user databases and I wish that too. What I don't agree with is something that casts that requirement in stone by architecturally/permanently disallowing secondary connections. Evidence for claims: * The whole Business Intelligence industry relies on being able to re-purpose existing data, forming integrated webs of interconnecting databases. All of that happens after the initial developers write the first version of the database application. * Everybody wants a remote backup, whether its for your mobile phone contact list or your enterprise datastore. People are migrating away from embedded databases in droves for these very reasons. > The main disadvantage of approaching this via the existing single-user > mode is that you won't have any autovacuum, bgwriter, etc, support. > But the flip side is that that lack of infrastructure is a positive > advantage for certain admittedly narrow use-cases, such as disaster > recovery and pg_upgrade. So while I agree that this isn't the only > form of single-user mode that we'd like to support, I think it is *a* > form we'd like to support, and I don't see why you appear to be against > having it at all. I have no problem with people turning things off, I reject the idea that we should encourage people to never be able to turn them back on. > A more reasonable objection would be that we need to make sure that this > isn't foreclosing the option of having a multi-process environment with > a single user connection. I don't see that it is, but it might be wise > to sketch exactly how that case would work before accepting this. Whatever we provide will become the norm. I don't have a problem with you providing BOTH the proposed single user mode AND the multi-process single user connection mode in this release. But if you provide just one of them and its the wrong one, we will be severely hampered in the future. Yes, I am very much against this project producing a new DBMS architecture that works on top of PostgreSQL data files, yet prevents maintenance, backup, replication and multi-user modes. I see this decision as a critical point for this project, so please consider this objection and where it comes from. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
pgsql-hackers by date: