Thread: PostgreSQL windows native port available
Dear Dave, Some hackers are now discussing about importing PostgreSQL Windows port http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html into PostgreSQL main tree. How long would it take to release a clean installer for PostgreSQLe existing binaries. Some say it is a very stable solution. This would be nice to release both pgAdmin2 and PostgreSQL on bloodshed. Cheers, Jean-Michel POURE
> -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr] > Sent: 10 May 2002 10:07 > To: pgadmin-hackers@postgresql.org > Cc: Dave Page > Subject: [pgadmin-hackers] PostgreSQL windows native port available > > > Dear Dave, > > Some hackers are now discussing about importing PostgreSQL > Windows port > http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html into > PostgreSQL main > tree. > > How long would it take to release a clean installer for > PostgreSQLe existing > binaries. Some say it is a very stable solution. This would > be nice to > release both pgAdmin2 and PostgreSQL on bloodshed. Have you actually tried it? I did last night & deleted it shortly afterwards. There are a number of problems: 1) All databases are EUC_JP encoded. 2) It doesn't run as a service, but as an application. 3) It doesn't support multi-session (from the docs, I'm not sure what it means, but perhaps 5). 4) It doesn't support transaction isolation. 5) It crashes with more than one pgbench connection. Basically, I think they just ripped out all the things that are a problem in Win32 (like fork() & IPC) and made a single user version, rather than writing Win32 versions. I think that a stripped down cygwin version is the (easy) way forward. I think that's what MySQL do, certainly the cygwin dll is distributed with it. All that is really required is the rewriting of probably pg_dumpall, initdb & initlocation - the rest of the scripts aren't needed, and a binary-only version would then be easy bar licencing issues. Writing an installer is easy enough as well... Regards, Dave.
Le Vendredi 10 Mai 2002 11:21, Dave Page a écrit : > I think that a stripped down cygwin version is the (easy) way forward. I > think that's what MySQL do, certainly the cygwin dll is distributed with > it. All that is really required is the rewriting of probably pg_dumpall, > initdb & initlocation - the rest of the scripts aren't needed, and a > binary-only version would then be easy bar licencing issues. > > Writing an installer is easy enough as well... Dear Robert, Dave Page, pgAdmin2 author (http://pgadmin.postgresql.org), and I have been discussing for a long time to find a proper way to distribute PostgreSQL using a minimal Cygwin layer. Do not hesitate to correct me if I am wrong : Dear Dave, Robert Collins wrote me to explain quite a few tricks about Cygwin setup.exe installer: 1) Latest CVS Cygwin setup.exe supports scripting. I don't know in what extent installation features are mapped. At least, this means we should try the latest CVS version. 2) setup.exe is not needed if you know WHICH packages are required (with no relation to scripting). You simply need to provide path and everything in a proper setup.ini file. Et voilà. Setup.exe would be installed by our installer in the proper folder but not used. Users could possibly run setup.exe for upgrades. 3) setup.exe supports post-installation scripts. This may allow us to make a minimal PostgreSQL install of Template1, enable a TCP/IP socket, etc... inside a Cygwin package (example : run a bash script or connect locally using SSH to su under postgres user). Otherwize, we could do it manually using an installer script. Good news, no? Cheers, Jean-MIchel
> -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr] > Sent: Friday, May 10, 2002 8:29 PM > Robert Collins wrote me to explain quite a few tricks about > Cygwin setup.exe > installer: > > 1) Latest CVS Cygwin setup.exe supports scripting. I don't > know in what extent > installation features are mapped. At least, this means we > should try the > latest CVS version. Actually, the last 3-4 versions have all supported scripting and dependencies. There's currently a nasty parser overflowbecause the setup.ini got too big, but I've just fixed this and am committing a CVS fix asap. Certainly I encourageexperimentation and am happy to discuss what can be done. The official setup.exe mailing list is cygwin-apps@cygwin.com.Currently there are ~4-5 folk actively contributing setup.exe code, so things that take someones interesthappen fairly quickly. > 2) setup.exe is not needed if you know WHICH packages are > required (with no > relation to scripting). You simply need to provide path and > everything in a > proper setup.ini file. Et voilà. The KDE on cygwin group use this approach (they distribute binaries via a setup.ini site, but don't distribute setup.exeat all). You simply add a user URL to setup.exe when you run it, and it picks up your package, merges it into thelist, and will install any needed packages from any other site as listed by your 'requires:' statement. > 3) setup.exe supports post-installation scripts. This may > allow us to make a > minimal PostgreSQL install of Template1, enable a TCP/IP > socket, etc... > inside a Cygwin package (example : run a bash script or > connect locally using > SSH to su under postgres user). Otherwize, we could do it > manually using an > installer script. Yes. Also setup supports pre-removal scripts, to allow tidying things up. Cheers, Rob
> -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr] > Sent: 10 May 2002 11:29 > To: Dave Page; pgadmin-hackers@postgresql.org > Cc: robert.collins@itdomain.com.au > Subject: Re: [pgadmin-hackers] PostgreSQL windows native port > available > > > Le Vendredi 10 Mai 2002 11:21, Dave Page a écrit : > > I think that a stripped down cygwin version is the (easy) > way forward. > > I think that's what MySQL do, certainly the cygwin dll is > distributed > > with it. All that is really required is the rewriting of probably > > pg_dumpall, initdb & initlocation - the rest of the scripts aren't > > needed, and a binary-only version would then be easy bar licencing > > issues. > > > > Writing an installer is easy enough as well... > > Dear Robert, > > Dave Page, pgAdmin2 author (http://pgadmin.postgresql.org), > and I have been > discussing for a long time to find a proper way to distribute > PostgreSQL > using a minimal Cygwin layer. Do not hesitate to correct me > if I am wrong : > > Dear Dave, > > Robert Collins wrote me to explain quite a few tricks about > Cygwin setup.exe > installer: > > 1) Latest CVS Cygwin setup.exe supports scripting. I don't > know in what extent > installation features are mapped. At least, this means we > should try the > latest CVS version. > > 2) setup.exe is not needed if you know WHICH packages are > required (with no > relation to scripting). You simply need to provide path and > everything in a > proper setup.ini file. Et voilà. > > Setup.exe would be installed by our installer in the proper > folder but not > used. Users could possibly run setup.exe for upgrades. > > 3) setup.exe supports post-installation scripts. This may > allow us to make a > minimal PostgreSQL install of Template1, enable a TCP/IP > socket, etc... > inside a Cygwin package (example : run a bash script or > connect locally using > SSH to su under postgres user). Otherwize, we could do it > manually using an > installer script. > > Good news, no? Hmmm. No offence to Robert, but I do not like the Cygwin installer (from a users pov, not a developers). I always seem tobe getting hassled to upgrade it, then when I do, I find it does things like preselect the oldest versions of each packagerather than the latest. I ran it the day before yesterday, and it didn't complain that it was out of date for once,but did completely fail to parse the file containing the package info on each of about 5 different mirrors that I tried:-( It is easily possible to create the required installer using Wise or Installshield (yes I know these aren't free), and boththese products could make use of the psqlODBC merge module, and install services & ODBC datasources easily and seamlesslywhich I suspect is more tricky (if not impossible) in the Cygwin installer (please correct me if I'm wrong). Installer technologies aside, one of the major reasons for this (and the other discussions on pgsql-hackers) is the wishto 'hide' Cygwin from the PostgreSQL user. We need to make it live in C:\Program Files\PostgreSQL, not have a completeunix style file layout, and generally look like a real Windows application. Cygwin is a great environment for workingin and porting software, but now that work is done, PostgreSQL (as an application) should use, and expose the absoluteminimum of Cygwin to the user. Regards, Dave.
> > Hmmm. No offence to Robert, but I do not like the Cygwin > installer (from a users pov, not a developers). I always seem > to be getting hassled to upgrade it, then when I do, I find > it does things like preselect the oldest versions of each > package rather than the latest. I ran it the day before > yesterday, and it didn't complain that it was out of date for > once, but did completely fail to parse the file containing > the package info on each of about 5 different mirrors that I tried :-( Yeah. This is unfortunate. We had a right hand recursion in the yacc parser, and that overflowed the stack when MD5 data was added to the production .ini's... AND the package list went from 165 to 166 packages. Who could have known? Anyway I've a fix for it now that I've had a few minutes to do non-work things, and am about to upload a new snapshot binary to get folk going again. > It is easily possible to create the required installer using > Wise or Installshield (yes I know these aren't free), and > both these products could make use of the psqlODBC merge > module, and install services & ODBC datasources easily and > seamlessly which I suspect is more tricky (if not impossible) > in the Cygwin installer (please correct me if I'm wrong). For setup.exe you could have a small commandline tool to call those services, and call it in a post-install script. Similar things are done for other packages in cygwin today. > Installer technologies aside, one of the major reasons for > this (and the other discussions on pgsql-hackers) is the wish > to 'hide' Cygwin from the PostgreSQL user. We need to make it > live in C:\Program Files\PostgreSQL, not have a complete unix > style file layout, and generally look like a real Windows > application. Cygwin is a great environment for working in and > porting software, but now that work is done, PostgreSQL (as > an application) should use, and expose the absolute minimum > of Cygwin to the user. You should rebuild cygwin with a different shared memory area then, to avoid the -inevitable- shared memory area versioning conflicts that will arise. Cygwin1.dll needs to share data across process's, and that is done via a named shared memory area. If your copy of cygwin1.dll is different to a version the user installs elsewhere, you will have trouble (unless you've rebuilt cygwin with a different memory area). I'd suggest that you simply install cygwin in it's usual place, and forget about it... Anyway, that's a different issue as it is orthogonal to the installer that is used. BTW: Jason Tishler may be interested in what you are doing, he maintains the current Cygwin postgreSQL port. Rob
> -----Original Message----- > From: Robert Collins [mailto:robert.collins@itdomain.com.au] > Sent: 10 May 2002 11:56 > To: Dave Page; jm.poure@freesurf.fr; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] PostgreSQL windows native port > available > > > > Installer technologies aside, one of the major reasons for > > this (and the other discussions on pgsql-hackers) is the wish > > to 'hide' Cygwin from the PostgreSQL user. We need to make it > > live in C:\Program Files\PostgreSQL, not have a complete unix > > style file layout, and generally look like a real Windows > > application. Cygwin is a great environment for working in and > > porting software, but now that work is done, PostgreSQL (as > > an application) should use, and expose the absolute minimum > > of Cygwin to the user. > > You should rebuild cygwin with a different shared memory area > then, to avoid the -inevitable- shared memory area versioning > conflicts that will arise. Cygwin1.dll needs to share data > across process's, and that is done via a named shared memory > area. If your copy of cygwin1.dll is different to a version > the user installs elsewhere, you will have trouble (unless > you've rebuilt cygwin with a different memory area). > > I'd suggest that you simply install cygwin in it's usual > place, and forget about it... Anyway, that's a different > issue as it is orthogonal to the installer that is used. To be honest, if I get involved at all it will only be from a packaging pov - there are others far more qualified than me who are looking at how exactly the port should be built, ie. Should we change at all, should we use a cutdown version or the current package (my opinion obviously), or should we write our own IPC, & fork() etc. > BTW: Jason Tishler may be interested in what you are doing, > he maintains the current Cygwin postgreSQL port. Yes, I exchanged email on the subject with Jason yesterday. Regards, Dave.