Re: Proof of concept: standalone backend with full FE/BE protocol
От | Amit kapila |
---|---|
Тема | Re: Proof of concept: standalone backend with full FE/BE protocol |
Дата | |
Msg-id | 6C0B27F7206C9E4CA54AE035729E9C382853149B@szxeml509-mbs обсуждение исходный текст |
Ответ на | Re: Proof of concept: standalone backend with full FE/BE protocol (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proof of concept: standalone backend with full FE/BE protocol
Re: Proof of concept: standalone backend with full FE/BE protocol |
Список | pgsql-hackers |
On Friday, September 07, 2012 11:19 PM Tom Lane wrote: Heikki Linnakangas <hlinnaka@iki.fi> writes: >> Would socketpair(2) be simpler? >I've not done anything yet about the potential security issues >associated with untrusted libpq connection strings. I think this >is still at the proof-of-concept stage; in particular, it's probably > time to see if we can make it work on Windows before we worry more >about that. I have started working on this patch to make it work on Windows. The 3 main things to make it work are: 1. Windows equivalent for socketpair - This as suggested previously in this thread earlier code of pgpipe can suffice theneed. Infact I have checked on net as well, most implementations are similar to pgpipe implementation. So I prefered touse the existing code which was removed. 2. Windows equivalent for fork-execv - This part can be done by CreateProcess,it can be similar to internal_forkexec exceptfor path where it uses shared memory to pass parameters, I am trying to directly pass parameters to CreateProcess. 3. Windows equivalent for waitpid - Actually there can be 2 ways to accomplish this a. use waitforsingleobject with process handle, but in some places it is mentioned it might not work forall windows versions. Can someone pls confirm about. I shall try on my PC to test the same. b. use existing infrastructureof waitpid, however it is not for single process and it might need some changes to make it work for singleprocess or may be we can use it directly. However currentlyit is in postmaster.c, so it need to be moved so that we can access it from fe-connect.c in libpq as well. c. suggest if you know of other ways to handle it or which from above2 would be better? Some other doubts: 1. does this follow the behavior that admin users will not be allowed to invoke postgres child process? 2. to find standalone_backend incase user didn't input, do we need mechanism similar to getInstallationPaths()? Any other comments/suggestions? With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: