Re: Proof of concept: standalone backend with full FE/BE protocol
От | Daniel Farina |
---|---|
Тема | Re: Proof of concept: standalone backend with full FE/BE protocol |
Дата | |
Msg-id | CAAZKuFbFF+_=ibw4Hd_NRmtxiNEs34ZfR-=kdn_1+dSTB6Apsg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proof of concept: standalone backend with full FE/BE protocol (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Proof of concept: standalone backend with full FE/BE protocol
|
Список | pgsql-hackers |
On Wed, Sep 5, 2012 at 3:17 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On 9/5/12 5:59 PM, Daniel Farina wrote: >> I agree with this, even though in theory (but not in practice) >> creative use of unix sockets (sorry windows, perhaps some >> port-allocating and URL mangling can be done instead) and conventions >> for those would allow even better almost-like-embedded results, >> methinks. That may still be able to happen. > > Sure, everyone who cares can already do this, but some people probably > don't care enough. Also, making this portable and robust for everyone > to use, not just your local environment, is pretty tricky. See > pg_upgrade test script, for a prominent example. To my knowledge, no one has even really seriously tried to package it yet and then told the tale of woe, and it was an especially un-gratifying exercise for quite a while on account of multiple postgreses not getting along on the same machine because of SysV shmem. The bar for testing is a lot different than pg_upgrade (where a negative consequence is confusing and stressful downtime), and many programs use fork/threads and multiple connections even in testing, making its requirements different. So consider me still skeptical given the current reasoning that unix sockets can't be a good-or-better substitute, and especially accounting for programs that need multiple backends. -- fdr
В списке pgsql-hackers по дате отправления: