Re: [PATCHES] initdb in C
Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: 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 had some concern about whether Andrew's rewrite had tracked all the recent changes to the initdb shell-script sources. Are you both confident that it is up to date? Yes. Bruce has picked up the one change I didn't track (revision 1.204). cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] initdb in C
Bruce Momjian wrote: 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. I will double check this over the weekend. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] alter schema help is not available in psql
Repost: On Tue, 4 Nov 2003, Kris Jurka wrote: > > in psql \h alter schema does not produce the desired help because the sgml > doc has the incorrect tag so it does not get picked up by > the create_help.pl script. > > Kris Jurka > Index: doc/src/sgml/ref/alter_schema.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ref/alter_schema.sgml,v retrieving revision 1.4 diff -c -r1.4 alter_schema.sgml *** doc/src/sgml/ref/alter_schema.sgml 12 Sep 2003 00:12:47 - 1.4 --- doc/src/sgml/ref/alter_schema.sgml 4 Nov 2003 15:15:37 - *** *** 6,12 ALTER SCHEMA ! SQL - Schema Statements --- 6,12 ALTER SCHEMA ! SQL - Language Statements ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] alter schema help is not available in psql
Kris Jurka writes: > > in psql \h alter schema does not produce the desired help because the sgml > > doc has the incorrect tag so it does not get picked up by > > the create_help.pl script. Thanks for the reminder. Patch installed. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] initdb in C
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
Re: [pgsql-hackers-win32] [PATCHES] initdb in C
Andrew Dunstan wrote: > > > Tom Lane wrote: > > >Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > > >>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 had some concern about whether Andrew's rewrite had tracked all the > >recent changes to the initdb shell-script sources. Are you both > >confident that it is up to date? > > > > > > > > Yes. Bruce has picked up the one change I didn't track (revision 1.204). Yes, I was concerned too that everything was in there. I checked the initdb.sh logs and found that the only thing not added was the checking of the max number of connections before checking the max number of buffers, which I added. The other stuff was in there. I also checked pg_id's recent changes and those were in there too. Andrew, I assume this was a new implementation of initdb, and not taken from an older initdb C implementation made by a company. This isn't really a patch but a C replacement of a critical shell script so there is reason to double-check things. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-hackers-win32] [PATCHES] initdb in C
Bruce Momjian wrote: Yes, I was concerned too that everything was in there. I checked the initdb.sh logs and found that the only thing not added was the checking of the max number of connections before checking the max number of buffers, which I added. The other stuff was in there. I also checked pg_id's recent changes and those were in there too. Andrew, I assume this was a new implementation of initdb, and not taken from an older initdb C implementation made by a company. This isn't really a patch but a C replacement of a critical shell script so there is reason to double-check things. Yes, I worked from initdb.sh, not from any other source. It's "all my own work" :-) I think I started with 1.201 and later upgraded to 1.203. I agree it needs careful checking - the more eyeballs the better. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [pgsql-hackers-win32] initdb in C
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.
Good. I can do rmdir() in C in port/dirmod.c if we need it. Right now
we are doing system(rm/rmdir) in dbcommands.c so we should consistent.
Let's stay with system(rm/rmdir) and if it doesn't work as we expect, we
can add your rmdir() code and put it in port/dirmod.c.
> 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
Peter, I thought we add:
#endif /* port... */
only when the define covers many lines of code. This case:
#ifdef WIN32
some code
#endif
seems clearer than:
#ifdef WIN32
some code
#endif /* WIN32 */
Of course, if the code block is very large, a closing comment can
sometimes help. Personally, I don't like the comments anytime, but if
people like them on long blocks, I can understand that.
> 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.
Done.
> 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.
I am confused. The only change I made was to have the quotes appear
only on WIN32.
#ifndef WIN32
#define QUOTE_PATH ""
#else
#define QUOTE_PATH "\""
#endif
...
printf("\n"
"Success. You can now start the database server using:\n\n"
"%s/postmaster -D %s%s%s\n"
"or\n"
"%s/pg_ctl -D %s%s%s -l logfile start\n\n",
pgpath, QUOTE_PATH, pg_data, QUOTE_PATH,
pgpath, QUOTE_PATH, pg_data, QUOTE_PATH);
(I also merged multiple \n into a single line.) My logic was that
spaces in directory names are much more common on WIN32, so we should
display the quotes only on WIN32. Perhaps you read "\"" as "\\"?
> (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.
Thanks for reviewing my work. I am surprised how small the new initdb.c
is. It is 50k vs 38k for initdb.sh. Of course, system_views.sql is
another 10k, but still, it is smaller than I thought, and quite clear.
Thanks.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-hackers-win32] [PATCHES] initdb in C
Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > >Yes, I was concerned too that everything was in there. I checked the > >initdb.sh logs and found that the only thing not added was the checking > >of the max number of connections before checking the max number of > >buffers, which I added. The other stuff was in there. I also checked > >pg_id's recent changes and those were in there too. > > > >Andrew, I assume this was a new implementation of initdb, and not taken > >from an older initdb C implementation made by a company. > > > >This isn't really a patch but a C replacement of a critical shell > >script so there is reason to double-check things. > > > > > > > Yes, I worked from initdb.sh, not from any other source. It's "all my > own work" :-) I think I started with 1.201 and later upgraded to 1.203. > > I agree it needs careful checking - the more eyeballs the better. The great part is that it look so much like our code, unlike the commerical port code I have seen for initdb in the past. This certainly moves us forward on Win32. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] alter schema help is not available in psql
Thanks, I was just getting to this today, but Peter has applied it. Thanks. --- Kris Jurka wrote: > > Repost: > > On Tue, 4 Nov 2003, Kris Jurka wrote: > > > > > in psql \h alter schema does not produce the desired help because the sgml > > doc has the incorrect tag so it does not get picked up by > > the create_help.pl script. > > > > Kris Jurka > > Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] initdb in C
Andrew Dunstan writes: > recreating the datadir if we didn't create it initially should be OK in > that case, and it makes the code simpler. That should be avoided, because you'll have trouble recreating the original directory with all its properties such as ownership, permissions, etc., at least not without making the code anything but simpler. There might even be a situation were you are allowed to delete the directory but cannot create a new one. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [pgsql-hackers-win32] initdb in C
Bruce Momjian wrote:
Andrew Dunstan wrote:
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.
Good. I can do rmdir() in C in port/dirmod.c if we need it. Right now
we are doing system(rm/rmdir) in dbcommands.c so we should consistent.
Let's stay with system(rm/rmdir) and if it doesn't work as we expect, we
can add your rmdir() code and put it in port/dirmod.c.
In view of Peter's email of a few minutes ago I think we need to do that.
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.
I am confused. The only change I made was to have the quotes appear
only on WIN32.
#ifndef WIN32
#define QUOTE_PATH ""
#else
#define QUOTE_PATH "\""
#endif
...
printf("\n"
"Success. You can now start the database server using:\n\n"
"%s/postmaster -D %s%s%s\n"
"or\n"
"%s/pg_ctl -D %s%s%s -l logfile start\n\n",
pgpath, QUOTE_PATH, pg_data, QUOTE_PATH,
pgpath, QUOTE_PATH, pg_data, QUOTE_PATH);
(I also merged multiple \n into a single line.) My logic was that
spaces in directory names are much more common on WIN32, so we should
display the quotes only on WIN32. Perhaps you read "\"" as "\\"?
Yes, I did. Sorry about that. But we also need to quote the path (the
most obvious place to put it after all is "C:\Program
Files\PostgreSQL"). In fact, that's more important than the data
location. Unfortunately, the Windows command processor barfs on multiple
quotes strings ;-(
cheers
andrew
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] initdb in C
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Andrew Dunstan writes: >> recreating the datadir if we didn't create it initially should be OK in >> that case, and it makes the code simpler. > That should be avoided, because you'll have trouble recreating the > original directory with all its properties such as ownership, permissions, > etc., at least not without making the code anything but simpler. There > might even be a situation were you are allowed to delete the directory but > cannot create a new one. Consider also the strong likelihood that the data directory's parent directory is owned by root, so that you do not have the ability to delete and recreate the data directory because you don't have write permission on its parent. The main reason initdb is set up to be able to start with an existing-but-empty data dir is exactly because creating that directory may have required permissions that initdb itself hasn't got. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] ALTER TABLE modifications
A general re-organization of Alter Table. Node wise, it is a
AlterTableStmt with a list of AlterTableCmds. The Cmds are the
individual actions to be completed (Add constraint, drop constraint, add
column, etc.)
Processing is done in 2 phases. The first phase updates the system
catalogs and creates a work queue for the table scan. The second phase
is to conduct the actual table scan evaluating all constraints and other
per tuple processing simultaneously, as required. This has no effect on
single step operations, but has a large benefit for combinational logic
where multiple table scans would otherwise be required.
Steps for the table scan include expression processing (default or
transform expressions), not null constraint process, other constraints.
The code has been simplified a little. Simple permission and recursion
checks are conducted in the common area and an enum for the command type
is used rather than a Char.
ALTER TABLE ADD COLUMN col DEFAULT 3 NOT NULL;
Allow creation of a column with a default (filled) and not null
constraint. This is internally subdivided into 3 actions much
like the below syntax.
ALTER TABLE tab ADD COLUMN col DEFAULT 3, ADD CHECK (anothercol > 3);
The above combinational syntax is commented out in gram.y. The
support framework is used in both the above and below items, but
arbitrary statements probably have some issues -- I've not
tested enough to determine.
If it is useful, it will be submitted at a later date.
ALTER TABLE tab ALTER COLUMN col TYPE text TRANSFORM ...;
Currently migrates indexes, check constraints, defaults, and the
column definition to the new type with optional transform. If
the tranform is not supplied, a standard assignment cast is
attempted.
One issue is that it detects dependencies way too late in the
game (after the TRANFORM has been applied). I tried mucking up
performDeletion to have a RESTRICT that did not throw the error
at the end (or physically remove the items) but that didn't work
out. Any bright ideas on how to achieve the NOTICES from a
failed DROP COLUMN earlier? Otherwise, I can put in single
object detection at that point.
It does not migrate foreign keys yet (should be easy to add) and
will be forwarded as an independent patch at a later time.
Currently foreign keys are rejected like views, functions, etc.
Comments appreciated.
--
Rod Taylor
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
altertable.patch.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] initdb in C
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Andrew Dunstan writes: > >> recreating the datadir if we didn't create it initially should be OK in > >> that case, and it makes the code simpler. > > > That should be avoided, because you'll have trouble recreating the > > original directory with all its properties such as ownership, permissions, > > etc., at least not without making the code anything but simpler. There > > might even be a situation were you are allowed to delete the directory but > > cannot create a new one. > > Consider also the strong likelihood that the data directory's parent > directory is owned by root, so that you do not have the ability to > delete and recreate the data directory because you don't have write > permission on its parent. The main reason initdb is set up to be able > to start with an existing-but-empty data dir is exactly because creating > that directory may have required permissions that initdb itself hasn't > got. Again, this directory recreate happens only on Win32, an I thought it would be OK there. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] initdb in C
Peter Eisentraut wrote: > Andrew Dunstan writes: > > > recreating the datadir if we didn't create it initially should be OK in > > that case, and it makes the code simpler. > > That should be avoided, because you'll have trouble recreating the > original directory with all its properties such as ownership, permissions, > etc., at least not without making the code anything but simpler. There > might even be a situation were you are allowed to delete the directory but > cannot create a new one. Recreating the directory only happens on WIN32, where rmdir doesn't allow you to only delete files and subdirectories and not the parent directory. Non-Win32 does rm -rf dir/*. Is that OK? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] initdb in C
Bruce Momjian <[EMAIL PROTECTED]> writes: >> Consider also the strong likelihood that the data directory's parent >> directory is owned by root, > Again, this directory recreate happens only on Win32, an I thought it > would be OK there. Windows has no concept of directory permissions at all? I thought the more recent versions had at least rudimentary permissions. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] initdb in C
Bruce Momjian <[EMAIL PROTECTED]> writes: > Recreating the directory only happens on WIN32, where rmdir doesn't > allow you to only delete files and subdirectories and not the parent > directory. Non-Win32 does rm -rf dir/*. I think we should forget about invoking rm as a subprocess at all, and just do the recursive directory walk and unlinks for ourselves. We already have code to do this for copy in copydir.c, and unlink would not be any longer. We will probably be forced into implementing database removal for ourselves rather than by 'rm' hacks anyway as soon as tablespaces come to pass; so why contort initdb's behavior for a very transient implementation savings? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] initdb in C
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > >> Consider also the strong likelihood that the data directory's parent > >> directory is owned by root, > > > Again, this directory recreate happens only on Win32, an I thought it > > would be OK there. > > Windows has no concept of directory permissions at all? I thought the > more recent versions had at least rudimentary permissions. I found "del" works for what we need. I have posted the new code already. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] initdb in C
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Recreating the directory only happens on WIN32, where rmdir doesn't > > allow you to only delete files and subdirectories and not the parent > > directory. Non-Win32 does rm -rf dir/*. > > I think we should forget about invoking rm as a subprocess at all, and > just do the recursive directory walk and unlinks for ourselves. We > already have code to do this for copy in copydir.c, and unlink would not > be any longer. We will probably be forced into implementing database > removal for ourselves rather than by 'rm' hacks anyway as soon as > tablespaces come to pass; so why contort initdb's behavior for a very > transient implementation savings? If we want to do that, fine, but I don't want to force the change just for Win32. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [pgsql-hackers-win32] initdb in C
Andrew Dunstan wrote:
> >Good. I can do rmdir() in C in port/dirmod.c if we need it. Right now
> >we are doing system(rm/rmdir) in dbcommands.c so we should consistent.
> >Let's stay with system(rm/rmdir) and if it doesn't work as we expect, we
> >can add your rmdir() code and put it in port/dirmod.c.
> >
> >
>
> In view of Peter's email of a few minutes ago I think we need to do that.
Again, recreate is only Win32. I just figured out how to do this on
Win32. We have to use 'del' rather than 'rmdir' to keep the directory:
New code is:
/*
* delete a directory tree recursively
* assumes path points to a valid directory
* deletes everything under path
* if rmtopdir is true deletes the directory too
*
*/
static bool
rmtree(char *path, bool rmtopdir)
{
charbuf[MAXPGPATH + 64];
#ifndef WIN32
/* doesn't handle .* files */
snprintf(buf, sizeof(buf), "rm -rf '%s%s'", path,
rmtopdir ? "" : "/*");
#else
snprintf(buf, sizeof(buf), "%s /s /q \"%s\"",
rmtopdir ? "rmdir" : "del", path);
#endif
return !system(buf);
}
> >printf("\n"
> > "Success. You can now start the database server using:\n\n"
> > "%s/postmaster -D %s%s%s\n"
> > "or\n"
> > "%s/pg_ctl -D %s%s%s -l logfile start\n\n",
> >pgpath, QUOTE_PATH, pg_data, QUOTE_PATH,
> >pgpath, QUOTE_PATH, pg_data, QUOTE_PATH);
> >
> >(I also merged multiple \n into a single line.) My logic was that
> >spaces in directory names are much more common on WIN32, so we should
> >display the quotes only on WIN32. Perhaps you read "\"" as "\\"?
> >
> >
>
> Yes, I did. Sorry about that. But we also need to quote the path (the
> most obvious place to put it after all is "C:\Program
> Files\PostgreSQL"). In fact, that's more important than the data
> location. Unfortunately, the Windows command processor barfs on multiple
> quotes strings ;-(
I ran some tests using XP "CMD" and found:
"C:\test"
and
"\test"
works but:
"test"
does not work. Since I see that the output always has a leading path, I
have modified the code to do:
printf("\nSuccess. You can now start the database server using:\n\n"
"%s%s%s/postmaster -D %s%s%s\n"
"or\n"
"%s%s%s/pg_ctl -D %s%s%s -l logfile start\n\n",
QUOTE_PATH, pgpath, QUOTE_PATH, QUOTE_PATH, pg_data, QUOTE_PATH,
QUOTE_PATH, pgpath, QUOTE_PATH, QUOTE_PATH, pg_data, QUOTE_PATH);
I am attaching the updated initdb.c file.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
/*-
*
* initdb
*
* author: Andrew Dunstan mailto:[EMAIL PROTECTED]
*
* Copyright (C) 2003 Andrew Dunstan
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* This code is released under the terms of the PostgreSQL License.
*
* This is a C implementation of the previous shell script for setting up a
* PostgreSQL cluster location, and should be highly compatible with it.
*
* $Header$
*
* TODO:
* - clean up find_postgres code and return values
*
* Note:
* The program has some memory leakage - it isn't worth cleaning it up.
* Even before the code was put in to free most of the dynamic memory
* used it ran around 500Kb used + malloc overhead. It should now use
* far less than that (around 240Kb - the size of the BKI file).
* If we can't load this much data into memory how will we ever run
* postgres anyway?
*
*-
*/
#include "postgres_fe.h"
#include "getopt_long.h"
#include
#include
#include
#include
#include
#include "libpq/pqsignal.h"
#include "mb/pg_wchar.h"
/* version string we expect back from postgres */
#define PG_VERSIONSTR "postgres (PostgreSQL) " PG_VERSION "\n"
/* values passed in by makefile define */
char *bindir = PGBINDIR;
char *datadir = PGDATADIR;
/* values to be obtained from arguments */
char *pg_data = "";
char *encoding = "";
char *locale = "";
char *lc_collate = "";
char *lc_ctype = "";
char *lc_monetary = "";
char *lc_numeric = "";
char *lc_time = "";
char *lc_messages = "";
char *username = "";
boolpwprompt = false;
booldebug = false;
boolnoclean =
Re: [PATCHES] initdb in C
Also, I see this at the top of the code: * author: Andrew Dunstan mailto:[EMAIL PROTECTED] * * Copyright (C) 2003 Andrew Dunstan * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California Can I remove the first copyright? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] initdb in C
Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: Consider also the strong likelihood that the data directory's parent directory is owned by root, Again, this directory recreate happens only on Win32, an I thought it would be OK there. Windows has no concept of directory permissions at all? I thought the more recent versions had at least rudimentary permissions. More than rudimentary on the server versions. I found this info at http://www.cs.wayne.edu/labPages/modes.htm : Windows ACLs Windows NT and Windows 2000 uses Access Control Lists or ACLs to determine what operations a user may perform on a file. Windows ACLs allow one to set permissions with finer control that does the Unix file mode. For example, one can all[ow] a user to append data to a file as opposed to overwiting the file. ACLs also allow one to permit specific users to change the permissions on a file. Perhaps the biggest difference is that ACLs allow us to accord permissions on a user-by-user basis, rather than the three categories of users permitted by Unix file systems. This info applies to directories as well as plain files AFAIK cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] initdb in C
Bruce Momjian wrote: Also, I see this at the top of the code: * author: Andrew Dunstan mailto:[EMAIL PROTECTED] * * Copyright (C) 2003 Andrew Dunstan * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California Can I remove the first copyright? Sure. I wasn't sure what our conventions were on that. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [pgsql-hackers-win32] initdb in C
Bruce Momjian wrote:
I ran some tests using XP "CMD" and found:
"C:\test"
and
"\test"
works but:
"test"
does not work. Since I see that the output always has a leading path,
On Windows, pgpath is guaranteed to be a full path (see call to
expanded_path() ) exactly so it works inside quotes using the Windows
command processor.
I
have modified the code to do:
printf("\nSuccess. You can now start the database server using:\n\n"
"%s%s%s/postmaster -D %s%s%s\n"
"or\n"
"%s%s%s/pg_ctl -D %s%s%s -l logfile start\n\n",
QUOTE_PATH, pgpath, QUOTE_PATH, QUOTE_PATH, pg_data, QUOTE_PATH,
QUOTE_PATH, pgpath, QUOTE_PATH, QUOTE_PATH, pg_data, QUOTE_PATH);
I am attaching the updated initdb.c file.
The problem with this is that you now have 2 quoted strings. This is
exactly the problem that I solved inside initdb by passing pg_data via
the environment rather than on the command line. "help cmd" on XP gives
you this info:
If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:
1. If all of the following conditions are met, then quote characters
on the command line are preserved:
- no /S switch
- exactly two quote characters
- no special characters between the two quote characters,
where special is one of: &<>()@^|
- there are one or more whitespace characters between the
the two quote characters
- the string between the two quote characters is the name
of an executable file.
2. Otherwise, old behavior is to see if the first character is
a quote character and if so, strip the leading character and
remove the last quote character on the command line, preserving
any text after the last quote character.
It is amazingly brain dead and cost me hours and hours of grief trying
to work out WTF was going on.
Offhand I can't think of a simple guaranteed to work command line for
the Windows message.
In the last resort we might need to look at having initdb create a .bat
file or two for us.
:-(((
cheers
andrew
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [PATCHES] [pgsql-hackers-win32] initdb in C
Andrew Dunstan wrote: The problem with this is that you now have 2 quoted strings. I take this back. You *can* have multiple quoted strings on the command line - it just doesn't work in popen() because it uses the /C flag. Sorry for my confusion. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [pgsql-hackers-win32] initdb in C
Andrew Dunstan wrote: > > > Andrew Dunstan wrote: > > > > > > > > > The problem with this is that you now have 2 quoted strings. > > > I take this back. You *can* have multiple quoted strings on the command > line - it just doesn't work in popen() because it uses the /C flag. Oh, OK, that's good. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] equal() perf tweak
Neil Conway <[EMAIL PROTECTED]> writes: > Interesting. I've heard in some shops it is standard policy to order > the fields in all structs by their descending sizes (making allowances > for platform-specific variations), so as to reduce padding. Do you > think it would be worthwhile to systematically make this kind of > reorganization throughout the backend? Not really. I'll go with ordering fields in a logical fashion (related fields together) every time. But when there's no particular semantic reason to choose one ordering over another, you might as well look at padding concerns for a tiebreaker. In this case there isn't any particular logical reason AFAICS to prefer whether length appears before or after head/tail, so why not pick the more compact form? (Note that I put a higher premium on avoiding padding in on-disk structures. But for transient in-memory structures, it definitely seems like a secondary consideration.) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Patch 7.4RC1 pgtcl to restore Tcl-8.0 compatibility for large obj fix
ljb <[EMAIL PROTECTED]> writes: > Here's the patch to restore libpgtcl compatibility with Tcl-8.0, which was > lost in 7.4RC1 with my other patch to fix corrupt binary large-object reads > and writes. This patch is against PostgreSQL-7.4RC1. Applied. Many thanks for double-checking it. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] WIN32_DEV CVS branch
We are no longer using the WIN32_DEV CVS branch. We are doing all Win32 work in HEAD now. I have already moved any WIN32_DEV changes up into HEAD. I have updated the Win32 web page to indicate this: http://momjian.postgresql.org/main/writings/pgsql/win32.html Marc, would you remove the nightly generation of the win32 tarballs? Thanks. I assume we can't remove the branch itself. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] sigpipe handling
Attatched is the latest version of my patch that makes the
signal(SIG_PIPE, SIG_IGN) calls around the send() syscall conditional:
they are not sufficient to ensure that multithreaded libpq users are not
killed by SIGPIPE signals, and they cause a noticable slowdown.
I've switched to a global flag, and two functions to get/set the flag.
Any other ideas how to protect libpq against SIGPIPE?
--
Manfred
Index: contrib/pgbench/README.pgbench
===
RCS file: /projects/cvsroot/pgsql-server/contrib/pgbench/README.pgbench,v
retrieving revision 1.9
diff -c -r1.9 README.pgbench
*** contrib/pgbench/README.pgbench 10 Jun 2003 09:07:15 - 1.9
--- contrib/pgbench/README.pgbench 8 Nov 2003 21:43:53 -
***
*** 112,117
--- 112,121
might be a security hole since ps command will
show the password. Use this for TESTING PURPOSE ONLY.
+ -a
+ Disable SIGPIPE delivery globally instead of within each
+ libpq operation.
+
-n
No vacuuming and cleaning the history table prior to the
test is performed.
Index: contrib/pgbench/pgbench.c
===
RCS file: /projects/cvsroot/pgsql-server/contrib/pgbench/pgbench.c,v
retrieving revision 1.27
diff -c -r1.27 pgbench.c
*** contrib/pgbench/pgbench.c 27 Sep 2003 19:15:34 - 1.27
--- contrib/pgbench/pgbench.c 8 Nov 2003 21:43:54 -
***
*** 28,33
--- 28,34
#else
#include
#include
+ #include
#ifdef HAVE_GETOPT_H
#include
***
*** 105,112
static void
usage()
{
! fprintf(stderr, "usage: pgbench [-h hostname][-p port][-c nclients][-t
ntransactions][-s scaling_factor][-n][-C][-v][-S][-N][-l][-U login][-P
password][-d][dbname]\n");
! fprintf(stderr, "(initialize mode): pgbench -i [-h hostname][-p port][-s
scaling_factor][-U login][-P password][-d][dbname]\n");
}
/* random number generator */
--- 106,113
static void
usage()
{
! fprintf(stderr, "usage: pgbench [-h hostname][-p port][-c nclients][-t
ntransactions][-s scaling_factor][-n][-C][-v][-S][-N][-l][-a][-U login][-P
password][-d][dbname]\n");
! fprintf(stderr, "(initialize mode): pgbench -i [-h hostname][-p port][-s
scaling_factor][-U login][-P password][-d][dbname][-a]\n");
}
/* random number generator */
***
*** 703,712
else if ((env = getenv("PGUSER")) != NULL && *env != '\0')
login = env;
! while ((c = getopt(argc, argv, "ih:nvp:dc:t:s:U:P:CNSl")) != -1)
{
switch (c)
{
case 'i':
is_init_mode++;
break;
--- 704,719
else if ((env = getenv("PGUSER")) != NULL && *env != '\0')
login = env;
! while ((c = getopt(argc, argv, "aih:nvp:dc:t:s:U:P:CNSl")) != -1)
{
switch (c)
{
+ case 'a':
+ #ifndef WIN32
+ signal(SIGPIPE, SIG_IGN);
+ #endif
+ PQsetsighandling(0);
+ break;
case 'i':
is_init_mode++;
break;
Index: doc/src/sgml/libpq.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v
retrieving revision 1.141
diff -c -r1.141 libpq.sgml
*** doc/src/sgml/libpq.sgml 1 Nov 2003 01:56:29 - 1.141
--- doc/src/sgml/libpq.sgml 8 Nov 2003 21:43:56 -
***
*** 645,650
--- 645,693
+
+
PQsetsighandlingPQsetsighandling
+
PQgetsighandlingPQgetsighandling
+
+
+Set/query SIGPIPE signal handling.
+
+ void PQsetsighandling(int internal_sigign);
+
+
+ int PQgetsighandling(void);
+
+
+
+
+ These functions allow to query and set the SIGPIPE signal handling
+ of libpq: by default, Unix systems generate a (fatal) SIGPIPE signal
+ on write attempts to a disconnected socket. Most callers expect a
+ normal error return instead of the signal. A normal error return can
+ be achieved by blocking or ignoring the SIGPIPE signal. This can be
+ done either globally in the application or inside libpq.
+
+
+ If internal signal handling is enabled (this is the default), then
+ libpq sets the SIGPIPE handler to SIG_IGN before every socket send
+ operation and restores it afterwards. This prevents libpq from
+ killing the application, at the cost of a slight performance
+ decrease. This approach is not reliable for multithreaded applications.
+
+
+ If internal signal handling is disabled, then the caller is
+ respons
Re: [PATCHES] [pgsql-hackers-win32] WIN32_DEV CVS branch
removed, and files from ftp have also been removed ... On Sat, 8 Nov 2003, Bruce Momjian wrote: > We are no longer using the WIN32_DEV CVS branch. We are doing all Win32 > work in HEAD now. I have already moved any WIN32_DEV changes up into > HEAD. I have updated the Win32 web page to indicate this: > > http://momjian.postgresql.org/main/writings/pgsql/win32.html > > Marc, would you remove the nightly generation of the win32 tarballs? > Thanks. I assume we can't remove the branch itself. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] BEGIN vs START TRANSACTION
Gaetano Mendola wrote:
> Hi all,
> why START TRANSACTION READ ONLY is allowed
> and not BEGIN READ ONLY ?
Seems it should be allowed so that BEGIN and START TRANSACTION behave
the same.
In fact, the BEGIN manual page says:
has the same functionality
as BEGIN.
which is currently not true because START TRANSACTION has additional
options. The following patch fixes it. I will put it into 7.5 after an
appropriate delay.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/ref/begin.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/begin.sgml,v
retrieving revision 1.26
diff -c -c -r1.26 begin.sgml
*** doc/src/sgml/ref/begin.sgml 9 Sep 2003 18:28:52 - 1.26
--- doc/src/sgml/ref/begin.sgml 9 Nov 2003 03:06:01 -
***
*** 21,26
--- 21,28
BEGIN [ WORK | TRANSACTION ]
+ [ ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ |
SERIALIZABLE } ]
+ [ READ WRITE | READ ONLY ]
***
*** 49,54
--- 51,63
other sessions will be unable to see the intermediate states
wherein not all the related updates have been done.
+
+
+If the isolation level or read/write mode is specified, the new
+transaction has those characteristics, as if
+
+was executed.
+
***
*** 65,70
--- 74,85
+
+
+See under about the meaning of the
+other parameters.
+
Index: doc/src/sgml/ref/start_transaction.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/start_transaction.sgml,v
retrieving revision 1.8
diff -c -c -r1.8 start_transaction.sgml
*** doc/src/sgml/ref/start_transaction.sgml 6 Nov 2003 22:08:14 - 1.8
--- doc/src/sgml/ref/start_transaction.sgml 9 Nov 2003 03:06:01 -
***
*** 33,41
This command begins a new transaction. If the isolation level or
read/write mode is specified, the new transaction has those
characteristics, as if was executed. In all other
!respects, the behavior of this command is identical to the command.
--- 33,40
This command begins a new transaction. If the isolation level or
read/write mode is specified, the new transaction has those
characteristics, as if was executed. It is the same
!as the command.
Index: src/backend/parser/gram.y
===
RCS file: /cvsroot/pgsql-server/src/backend/parser/gram.y,v
retrieving revision 2.437
diff -c -c -r2.437 gram.y
*** src/backend/parser/gram.y 6 Nov 2003 22:08:14 - 2.437
--- src/backend/parser/gram.y 9 Nov 2003 03:06:07 -
***
*** 3607,3617
n->options = NIL;
$$ = (Node *)n;
}
! | BEGIN_P opt_transaction
{
TransactionStmt *n = makeNode(TransactionStmt);
n->kind = TRANS_STMT_BEGIN;
! n->options = NIL;
$$ = (Node *)n;
}
| START TRANSACTION transaction_mode_list_or_empty
--- 3607,3617
n->options = NIL;
$$ = (Node *)n;
}
! | BEGIN_P opt_transaction transaction_mode_list_or_empty
{
TransactionStmt *n = makeNode(TransactionStmt);
n->kind = TRANS_STMT_BEGIN;
! n->options = $3;
$$ = (Node *)n;
}
| START TRANSACTION transaction_mode_list_or_empty
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] pg_autovacuum README patch
Yes, I have reverted the lines outlined below and am attaching the patch. --- Gaetano Mendola wrote: > Gaetano Mendola wrote: > > > > > > > > > --- README.good 2003-10-21 02:40:19.0 +0200 > > +++ README 2003-10-21 02:37:43.0 +0200 > > @@ -1,3 +1,3 @@ > > -PG_autovacuum README > > +pg_autovacuum README > > > > > > @@ -148,8 +148,8 @@ > >vacuum analyze is performed. > > > > -AnalyzeThreshold is equal to: > > +deleteThreshold is equal to: > > vacuum_base_value + (vacuum_scaling_factor * "number of tuples in the table") > > > > -VacuumThreshold is equal to: > > +insertThreshold is equal to: > > analyze_base_value + (analyze_scaling_factor * "number of tuples in the > > table") > > Was I wrong ? > > Regards > Gaeatano Mendola > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: contrib/pg_autovacuum/README.pg_autovacuum === RCS file: /cvsroot/pgsql-server/contrib/pg_autovacuum/README.pg_autovacuum,v retrieving revision 1.5 diff -c -c -r1.5 README.pg_autovacuum *** contrib/pg_autovacuum/README.pg_autovacuum 16 Oct 2003 03:47:28 - 1.5 --- contrib/pg_autovacuum/README.pg_autovacuum 9 Nov 2003 03:10:53 - *** *** 147,156 - If the number of (deletes + updates) > VacuumThreshold, then a vacuum analyze is performed. ! deleteThreshold is equal to: vacuum_base_value + (vacuum_scaling_factor * "number of tuples in the table") ! insertThreshold is equal to: analyze_base_value + (analyze_scaling_factor * "number of tuples in the table") The AnalyzeThreshold defaults to half of the VacuumThreshold since it --- 147,156 - If the number of (deletes + updates) > VacuumThreshold, then a vacuum analyze is performed. ! VacuumThreshold is equal to: vacuum_base_value + (vacuum_scaling_factor * "number of tuples in the table") ! AnalyzeThreshold is equal to: analyze_base_value + (analyze_scaling_factor * "number of tuples in the table") The AnalyzeThreshold defaults to half of the VacuumThreshold since it ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] "make check" improvement for cygwin
Patch applied to 7.4 and HEAD. Thanks.
---
Christopher Kings-Lynne wrote:
> I have attached a more comprehensive MSWIN FAQ patch. Basically, the
> instructions were way out of date and incorrect. Installing Postgres
> from Cygwin is easier these days than the FAQ would imply.
>
> This patch already includes Andrew's previous patch.
>
> Chris
>
> Andrew Dunstan wrote:
>
> >
> >
> > Tom Lane wrote:
> >
> >> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>> Well, I posted the note last night but I finished the patch today,
> >>> because
> >>> it was very simple and took so little time.
> >>>
> >>
> >>
> >> I've committed this with the later revision about the warning message,
> >> and some other minor cleanups. I added documentation in the "Regression
> >> Tests" chapter, but if there is anyplace else you want to mention it,
> >> send in a docs patch.
>
> Index: doc/FAQ_MSWIN
> ===
> RCS file: /projects/cvsroot/pgsql-server/doc/FAQ_MSWIN,v
> retrieving revision 1.15
> diff -c -r1.15 FAQ_MSWIN
> *** doc/FAQ_MSWIN 11 Nov 2002 20:04:05 - 1.15
> --- doc/FAQ_MSWIN 3 Nov 2003 08:08:13 -
> ***
> *** 2,37
>
> $Date: 2002/11/11 20:04:05 $
>
> ! 1. Install the latest Cygwin package, available at http://cygwin.com/.
> ! The Cygwin package provides a UNIX-like API on top of the Win32
> ! API.
>
> ! A pre-built PostgreSQL is part of the standard Cygwin distribution
> ! and is installed by Cygwin's setup.exe. You are encouraged to use
> ! this version unless it does not meet your needs. Please read the
> ! README file, /usr/doc/Cygwin/postgresql-${version}.README, where
> ! "${version}" is the version (e.g., 7.2).
>
> ! 2. Install the latest cygipc package, available at
> ! http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/cygipc/.
> ! Do not use versions prior to 1.04, they will not work.
>
> ! Use the following command to install the cygipc package:
>
> ! $ tar -C / -xjf cygipc-${version}.tar.bz2
>
> ! where "${version}" is the version (e.g., 1.11-1).
>
> ! 3. The Cygwin bin directory has to be placed in the path before the
> ! Windows program directories, because the sort.exe has to be taken
> ! from Cygwin, not Windows.
>
> ! 4. Start ipc-daemon from the cygipc package. Use "net start ipc-daemon",
> ! if ipc-daemon is installed as a service; otherwise, use "ipc-daemon &".
> ! This program needs to be running anytime you start the PostgreSQL
> ! server (postmaster) or initialize a database (initdb).
>
> ! 5. Proceed according to the INSTALL file (i.e., ./configure; make; etc.)
> noting the following Cygwin specific differences:
>
> o The GNU make command is called "make" not "gmake".
> --- 2,67
>
> $Date: 2002/11/11 20:04:05 $
>
> ! PostgreSQL requires the Cygwin set of libraries to be installed in
> ! order that it functions under Windows.
>
> ! This document assumes that you do not have Cygwin already installed
> ! on your system. If that is not the case, then you will need to
> ! adjust these instructions accordingly.
>
> ! 1. Download and run the Cygwin installer. Visit http://cygwin.com/ and
> ! click on the "Install Cygwin now' link. This will prompt you
> ! to download a "setup.exe". Save this file somewhere on your
> ! system and then execute it.
>
> ! 2. Proceed through the Cygwin install wizard. Choose 'Install from
> ! Internet', specify a Local Package Directory and choose a mirror
> ! site that's close to you. Leave everything else as-is.
>
> ! When you come to the point of choosing which packages to install,
> ! expand the 'Database' section and click 'Skip' next to PostgreSQL
> ! to change it to the latest version of PostgreSQL available for
> ! Cygwin.
>
> ! 3. Once the download and install process is complete, open a Cygwin
> ! shell and do the following:
>
> ! 3a. Start ipc-daemon2 for shared memory support. Use
> ! "net start ipc-daemon2", if you want ipc-daemon2 installed
> ! as a service; otherwise, use "ipc-daemon2 &". This program
> ! needs to be running anytime you start the PostgreSQL server
> ! (postmaster) or initialize a database (initdb).
>
> ! 3b. Use the initdb command to create a new database cluster. An
> ! example command would be:
>
> ! initdb -D /usr/local/pgsql/data -W -E LATIN1
> !
> ! Which will create a cluster in the /usr/local/pgsql/data
> ! directory, will prompt for a superuser password and will
> ! set the default database encoding to LATIN1.
> !
> ! 3c. Start up the postmas
