[HACKERS] possible to create CVS branch for proposed patch?
Jason Tishler and I are planning to create a patch to allow PostgreSQL to run directly as an NT service. I've submitted a similar patch which may well be incorporated into the next release of Cygipc, and we've got a plan for doing the same for PostgreSQL: see http://ontosys.com/phiki/PostgresqlNtServiceDesign I've vetted that plan past this group and have incorporated feedback. Getting to my question: Is it possible to create a CVS branch of the HEAD (tip) of the PostgreSQL CVS for us to use in this work? Having such a branch would allow Jason and I to coordinate our work easily, and it also gives the pgsql-hackers community an easy way to view (and review) our work. Once/if the work is stable and approved, we/someone could then use CVS tools to merge that branch back onto the main line and cease any further work on that branch. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
Re: [HACKERS] possible to create CVS branch for proposed patch?
On Wed, Feb 14, 2001 at 07:43:25PM +0100, Peter Eisentraut wrote: Seems like something that should be done in a separate wrapper program. Littering the backend with vast sections of platform-specific code that provides optional functional is probably not going to fly, if I can assess this group correctly. Our plan puts most of the work in a new NT/Cygwin-only version of backend/main.c. If we can use the existing signal() scheme to shut down PG, then we might not have to touch _anything_ else. What do you see in our plan that implies "vast sections of platform-specific code" "littering the backend"? If such changes are necessary, I want to know before we embark on this work. As far as this being "optional functional[ity]", I contend that PostgreSQL has no place as a ready-for-business tool on NT without this (or similar) work so that PG runs cleanly as a service, starting up and shutting down properly. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
[HACKERS] build WIN32 ODBC using VC++, not Cygwin/gcc
To build the PostgreSQL ODBC driver from CVS (or a recent snapshot/beta, I presume): the following steps worked for me: + Make sure that the psqlodbc.def file in interfaces/odbc is exactly as distributed or obtained from CVS, not the result of some prior build. + Run 'configure' _without_ '--with-odbc' to build PostgreSQL. + Follow the steps in interfaces/odbc/readme.txt to build the ODBC DLL using MS Visual C++. Building with '--with-odbc' will appear to work, but the resulting DLL (created by Cygwin gcc/tools) completely fails to work for me once installed. (It would have been nice if the documentation gave a hint about this. Or did I miss it? The presense of the readme.txt file does not suffice to make it clear that VC++ is the _only_ correct way to build the module for WIN32.) I also got confused when first building the DLL from VC++, because my prior efforts using '--with-odbc' left behind a psqlodbc.def file that is incorrect. My thanks to Hiroshi Inoue for helping me get past this. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
[HACKERS] command-line option for logfile
A command-line option for specifying the logfile would be very helpful on WIN32. When setting up PostgreSQL to run as an NT service, the only way I can see to redirect stdout/stderr to a file is to invoke postmaster via a wrapper sh/bash process. I suspect that this wrapper process would have to hang around as long as postmaster is running, although it might be possible to do an exec to overlay it. It would be nice to avoid this wrapper process. On Mon, Feb 05, 2001 at 06:01:10PM +0100, Peter Eisentraut wrote: There should be an option to put the server log somewhere, either a file or maybe a pipe, e.g., pg_ctl -l logfile pg_ctl -P 'magic-log-rotator -x -y -z' Or we could just switch over to syslog as the standard log destination... Not as long as all the good stuff goes to stderr. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
Re: [HACKERS] build WIN32 ODBC using VC++, not Cygwin/gcc
On Mon, Feb 05, 2001 at 08:06:28PM +0100, Peter Eisentraut wrote: + Run 'configure' _without_ '--with-odbc' to build PostgreSQL. I doubt you need that, since you don't use the makefiles. I stated that point for the benefit of those, like me, who are building all of PG from source, not just building ODBC. Using '--with-odbc' in such a case has two problems: 1) it builds a useless psqlodbc.dll; 2) it updates (AFAICT) psqlodbc.def to new data that will cause a later, independent, build of psqlodbc.dll via VC++ to fail. Building with '--with-odbc' will appear to work, but the resulting DLL (created by Cygwin gcc/tools) completely fails to work for me once installed. (It would have been nice if the documentation gave a hint about this. Or did I miss it? Something more detailed thatn "completely fails to work" might shed some light onto it. I had posted earlier messages with more details (which got no response other than from Mr. Hiroshi Inoue, who got me past the problem) so I didn't repeat them in that message. Anyway, here's what happens when I build psqlodbc.dll as part of a complete pgsql build, having configured with '--with-odbc': + The psqlodbc.dll file appears to build OK, with no warnings (that I recall). + When I overwrite my systemroot/system32/psqlodbc.dll with the one I just built, I then can no longer access any ODBC functions for PostgreSQL. In particular: + The 'PostgreSQL' driver does appear in the list of drivers in the ODBC control panel. However, its version company information is not available. + When I select an existing System DSN using the PostgreSQL driver and click Configure, I get the message "The setup routines for the PostgreSQL ODBC driver could not be accessed. Please reinstall the driver." + When I try to Add a new DSN using the PostgreSQL DSN, the same message results. + When I try to bring up my Zope website, which employs several ODBC connections (and is my only application using PG ODBC), accessing that site results in an application error from Zope/python saying "The instruction at '0x64eca3e5' referenced memory at '0x014f3e54'. The memory could not be 'read'.". Bringing up the VC++ debugger at that point gives me the message "Unhandled exception in python.exe (PSQLODBC.DLL): 0xC005: Access Violation". -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
[HACKERS] best windows ODBC driver for HEAD CVS version?
What PostgreSQL ODBC driver should I use on Windows NT with the latest version of PostgreSQL from CVS? I had been using psqlodbc.dll version 6.50. by Insight Distribution System, as made available on ftp.postgresql.org in the 'latest' folder. That worked OK with version 7.0.3 of PostgreSQL, and does pretty well with the head CVS version too. But... I'm using ODBC connections with Zope, and Zope was able to display table schemas when connected to PG 7.0.3. However, it doesn't display any schema information when using the same ODBC driver but connected to the latest/head version of PG. This makes me think that the 6.50 ODBC driver is not a good match to the latest version of PG. So I ran 'configure --with-odbc' when building PG from source, creating a new psqlodbc.dll file. But when I replace my %systemroot%/system32/psqlodbc.dll file (the version 6.50 one) with this new version, nothing about ODBC to PG works right anymore. Attempting to use the driver to create a new DSN gives the message "The setup routines for the PostgreSQL ODBC driver could not be accessed. Please reinstall the driver." Maybe I need to do something more to install it correctly, but I couldn't find any information about how to do that. Can someone tell me how to install this latest version of the ODBC driver? -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
[HACKERS] Re: Re: [GENERAL] Trouble porting postgreSQL to WinNT
On Tue, Jan 30, 2001 at 09:41:11AM -0800, Barry Lind wrote: Yes I had the same problem, but for me the reason was that I forgot to start the ipc-daemon before running initdb. Last night I had no problems installing beta4 on WinNT 4.0. Also, AFAICT, ipc-daemon must be running under the same NT logon as the logon that you're using to run initdb (or postmaster), or else you'll see initdb hang (but use lots of CPU). This a major PITA for me, because I went by the book (figuratively) and set up the postgres service to run under a 'postgres' NT logon account created for just that purpose. That means I have to run ipc-daemon logged on as postgres as well. That's not so bad, but now when I want to run 'make check' to run regression tests I have to logon as postgres to do that as well (since the tests run initdb and postmaster). Since Cygwin doesn't have any su/sudo (again, AFAICT) this means logging off my usual development logon, losing all my pretty windows, and into the postgres login. (Makes me appreciate Linux all the more, as if I needed that.) I don't understand why a single ipc-daemon process can't serve processes for multiple NT logons at once. Or can it, and I just don't have it set up right? -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
[HACKERS] plan for running postmaster directly as NT service
I'm using PostgreSQL on WinNT to support (along with Zope) several websites. I've currently got postmaster running as an NT service by wrapping it with the 'invoker' utility, but I'd prefer to have it run directly as a service so that it can be stopped cleanly. I now know the basics of how to extend a program to make it run directly as an NT service, as I've enhanced the Cygipc (Cygwin) 'ipc-daemon' process to do just that (and I've submitted the patch to the current maintainer of Cygipc). So now I'd like to do the same for postgres/postmaster, but I want you all to vet this plan before I invest much more time. For me, the fundamental question is: If I create a patch that implements this function, what will it take to get it into the main CVS version? Will some established PostgreSQL developer offer to review/champion/mentor my work? Expected plan of operation: 1) Administrator runs 'postgres --install-as-service'. Program installs NT registry entries and calls Windows APIs to register the service, leaving it ready for 'automatic' startup, but not starting the service. The ImagePath key value uses exactly the full path of the 'postgres' program that did the install. After installing the service the program returns immediately. 2) When starting the service from, say, the Services Control Panel, postgres is invoked with a new '--service' command-line flag. When the postgres program starts running it looks for this option right away (much like '-boot') and, finding it, starts up in postmaster mode and passes on the --services flag, causing the postmaster code to do the necessary magic to start up as an NT service. This does not involve any additional forks; the process splits into a supervisory thread and a main thread that runs the existing main work loop. 3) When the service is stopped, the supervisory service thread sends some kind of event/signal/semaphore/... to the main work thread, causing that thread to shut down as if 'pg_ctl -m fast stop' had been called [is this a good choice?]. 4) Administrator runs 'postgres --remove-as-service'. The program removes the registry data for the service and calls APIs to completely remove the service. It shuts down the service first if it's already running. Then it quits. Design questions: a) The 'install' and 'remove' code is quite bulky, although simple. Is it OK to create a new source file for it, rather than working it into some existing file? b) How can the service log error messages? Is there any syslog type facility? If not, is it OK to include a new output interface that would log to the NT event log? Or is there some better scheme? c) What is a good way for the supervisory thread to communicate with the main thread and shut it down cleanly? (I haven't studied the code to find the main wait/select loop yet. Sorry.) d) How can we insure that the ipc-daemon service starts before the postgres/postmaster service? I believe that NT has some facility that allows one service to request start-up of another service, but I have no idea how to make that happen. Your feedback on this plan is more than welcome. I'm willing to put time into getting this working, but only if I get some support from you all. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
[HACKERS] Re: FW: Postgresql on win32
On Mon, Jan 22, 2001 at 10:19:00PM +, Peter Mount wrote: While on this subject, does anyone have a version of cygipc that works with the current version of CygWin? What's on postgresql.org doesn't work, and the link on the site was broken. The latest cygipc distribution (source and binary) seems to be at http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/cygipc/index.html. Version 1.08 works fine for me, with the HEAD version of PostgreSQL and DLL version 1.1.7 of cygwin. I've been messing with ipc-daemon so that it can run as an NT service all by itself, with no funky wrappers like 'invoker' or 'srvany'. It's working pretty well, and even knows how to install and remove itself as a service. I'd be happy to make the patch available if anyone is interested in shaking it down. I plan to submit it to the guy who's currently maintaining cygipc. And then I'd like to get postmaster itself also running as an NT service, able to shut down cleanly when the service is stopped. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
