Re: initdb in C - Mailing list pgsql-patches
From | Bruce Momjian |
---|---|
Subject | Re: initdb in C |
Date | |
Msg-id | 200311102302.hAAN2Wn04492@candle.pha.pa.us Whole thread Raw |
In response to | Re: initdb in C (Andrew Dunstan <andrew@dunslane.net>) |
List | pgsql-patches |
Patch applied. We now have a C version of initdb! --------------------------------------------------------------------------- Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > >Here is a slightly modified version of Andrew's great work in making a C > >version of initdb. Other than minor cleanups, the only big change was > >to remove rmdir handling because we using rm -r and rmdir /s in > >commands/dbcommands.c, so we might as use the same thing for initdb.c > >rather than having code that traverses the directory tree doing 'rm'. > > > >The other change was to remove the unlink code and instead use > >port/dirmod.c's version. > > > >It passes all the regression tests. I have also included a diff against > >Andrew's version so you can see my changes. It seems Andrew had a very > >current version of initdb. The only update he missed was the change to > >test the number of connections before shared buffers --- I made that > >change myself. > > > >I would like to apply this in the next few days to HEAD before initdb.sh > >drifts. We are no longer using the WIN32_DEV branch because all our > >work is now in 7.5 head. > > > > > > My comments: > > I have no problem with shelling out to rmdir - although my goal was to > avoid shelling out to anything other than postgres itself. I think > recreating the datadir if we didn't create it initially should be OK in > that case, and it makes the code simpler. Not handling dot files in the > Unix case should also be fine, as we know the directory was empty to > start with and we don't create any. > > Regarding the #endif comments you removed - Peter had asked me to put > them in. See > http://archives.postgresql.org/pgsql-hackers/2003-10/msg00352.php > > You put a comment on canonicalise_path() asking if it is needed. The > short answer is very much "yes". The Windows command processor will > accept suitably quoted paths with forward slashes, but barfs badly with > mixed forward and back slashes. (See recent discussion on > hackers-win32).Removing the trailing slash on a path means we never get > ugly double slashes. Feel free to put that info in as a comment if you > think it is needed. > > The changes you made for the final message are not going to work for > Windows - if pgpath or pg_data contain spaces we need quotes (even on > Unix, although there most people know better than to put spaces in > names). Also see above about mixed slashes. Also, putting a \ before > pg_data will be nasty if it starts with a drive or network specifier - > or even without (you might turn a directory specifier into a network > drive specifier). It's just a message, though, and we shouldn't hold up > for that - we can patch it to get it right. > > (Getting the path and slash thing working portably was by far the > biggest headache in this project - the rest was just grunt work for the > most part, although I learned a few interesting things.) > > Otherwise I'm fine with this. > > cheers > > andrew > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
pgsql-patches by date: