[PATCHES] $PostgreSQL$ header -- Post 7.4 Release
New options file for CVSROOT.
Depending on the version of CVS (FreeBSD's CVS to be more specific) is
on the server you may need to manually place this file into the CVSROOT
directory beside the committed options,v file. The reason for this is
that someone missed adding the command to have this file copied on
commit.
Steps:
* cvs co CVSROOT
* cp options CVSROOT
* cvs add options
* cvs commit options
* (and possibly) cp options /repo/CVSROOT
The functionality may be tested by adding a $PostgreSQL$ header to one
file. $Id$ and $Header$ have not been disabled. That should wait until
everyone is comfortable with the change.
The below command may be used to convert most $Id$ and $Header$ tags to
$PostgreSQL$ on a checked out copy. Commit as usual.
find . \( -name *.[ch] -or -name Makefile \) \
-type f \
\! -path '*CVS*' \
-exec sed -e 's/$(?:Id|Header)[^$]*$/$PostgreSQL$/' -i.bak {} \;
In src/backend/utils/adt/inet_net_ntop.c and
src/backend/utils/adt/inet_net_pton.c it would appear that the $Id$ tag
is assigned to a variable (rcsid). It doesn't break anything on my
system to change it to $PostgreSQL$.
tag=PostgreSQL=CVSHeader
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] "make check" improvement for cygwin
Christopher, On Sat, Nov 08, 2003 at 10:47:45PM -0500, Bruce Momjian wrote: > > ! PostgreSQL requires the Cygwin set of libraries to be installed in ^^^ > > ! order that it functions under Windows. The phrase "Cygwin set of DLLs" is more accurate. Actually, the phrase "appropriate subset of Cygwin DLLs" is even better. > > ! 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. ^^^ The default will not work for all users. > > ! 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). The above is missing the "ipc-daemon2 --install-as-service" step. You may want to add installing postmaster as a service too. > > ! There are some points that are only relevant if you are building Cygwin > > ! PostgreSQL from source: > > ! > > ! 1. Set your path to use the Cygwin bin directory before the Windows > > ! utilities. Cygwin sort must be used in preference to Windows sort.exe. Is the above needed during runtime too? Sorry for being picky and not supplying a patch. Nevertheless, I appreciate you updating the README. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(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] "make check" improvement for cygwin
The phrase "Cygwin set of DLLs" is more accurate. Actually, the phrase "appropriate subset of Cygwin DLLs" is even better. Ok. ! 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. ^^^ The default will not work for all users. Why not? I tried it on a couple of machines... I particularly noted that it now installs cygipc by default.. ! 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). The above is missing the "ipc-daemon2 --install-as-service" step. You may want to add installing postmaster as a service too. Can you please specify the exact set of steps to make this work perfectly - I've never managed it myself... I managed to find your docs on it on the Net once, but I never got it working 100% ! There are some points that are only relevant if you are building Cygwin ! PostgreSQL from source: ! ! 1. Set your path to use the Cygwin bin directory before the Windows ! utilities. Cygwin sort must be used in preference to Windows sort.exe. Is the above needed during runtime too? Not on any machine I've installed on. I just left those steps in because they were in the old docs. Sorry for being picky and not supplying a patch. Nevertheless, I appreciate you updating the README. That's cool. I would appreciate your tips on installing as a service, however. Chris ---(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] "make check" improvement for cygwin
Jason Tishler writes: > > > ! 1. Set your path to use the Cygwin bin directory before the Windows > > > ! utilities. Cygwin sort must be used in preference to Windows sort.exe. > > Is the above needed during runtime too? Can anyone see *any* use of "sort" that would warrant the above step? -- Peter Eisentraut [EMAIL PROTECTED] ---(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] "make check" improvement for cygwin
! 1. Set your path to use the Cygwin bin directory before the Windows ! utilities. Cygwin sort must be used in preference to Windows sort.exe. Is the above needed during runtime too? Can anyone see *any* use of "sort" that would warrant the above step? I have no idea. I just left that in because it was in the original version. tsort steps? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] BEGIN vs START TRANSACTION
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: > Peter Eisentraut wrote: >> I object to adding unnecessary complications like that. > Shouldn't BEGIN and START TRANSACTION have the same mechanics? The > changes to the code were the addition of only one line. The rest of the > patch was docs. My initial reaction was the same as Peter's, but after seeing the small size of the patch I reconsidered. It seems to make sense that BEGIN should be an exact synonym for START TRANSACTION. Let me give you my logic on this --- if people think of BEGIN and START TRANSACTION as the same, and they do \h begin, they aren't going to see the read only and isolation options for START TRANSACTION, and I doubt they are going to think to look there because they think they are the same. That's why I think it is good to add those clauses to BEGIN WORK/TRANSACTION. Since BEGIN isn't standard, wouldn't it be time to redirect them on the BEGIN manpage to the START TRANSACTION manpage and tell them there that BEGIN does not support the full syntax of START TRANSACTION? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] "make check" improvement for cygwin
Christopher, On Mon, Nov 10, 2003 at 10:18:14PM +0800, Christopher Kings-Lynne wrote: > >The default will not work for all users. > > Why not? I tried it on a couple of machines... I particularly noted > that it now installs cygipc by default.. The user may be behind a firewall, so the default for "Select Your Internet Connection" may not be appropriate. > >You may want to add installing postmaster as a service too. > > Can you please specify the exact set of steps to make this work > perfectly - I've never managed it myself... I managed to find your > docs on it on the Net once, I can only recommend culling to relevant information from my README: http://www.tishler.net/jason/software/postgresql/postgresql-7.3.4.README > but I never got it working 100% Really? They always seem to work for me... :,) Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] "make check" improvement for cygwin
Peter, On Mon, Nov 10, 2003 at 03:48:07PM +0100, Peter Eisentraut wrote: > Jason Tishler writes: > > > > ! 1. Set your path to use the Cygwin bin directory before the Windows > > > > ! utilities. Cygwin sort must be used in preference to Windows sort.exe. > > > > Is the above needed during runtime too? > > Can anyone see *any* use of "sort" that would warrant the above step? Not in practice. I just dragged it along because it was in older versions of the FAQ. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] BEGIN vs START TRANSACTION
Jan Wieck wrote: > Bruce Momjian wrote: > > > Tom Lane wrote: > >> Bruce Momjian <[EMAIL PROTECTED]> writes: > >> > Peter Eisentraut wrote: > >> >> I object to adding unnecessary complications like that. > >> > >> > Shouldn't BEGIN and START TRANSACTION have the same mechanics? The > >> > changes to the code were the addition of only one line. The rest of the > >> > patch was docs. > >> > >> My initial reaction was the same as Peter's, but after seeing the small > >> size of the patch I reconsidered. It seems to make sense that BEGIN > >> should be an exact synonym for START TRANSACTION. > > > > Let me give you my logic on this --- if people think of BEGIN and START > > TRANSACTION as the same, and they do \h begin, they aren't going to see > > the read only and isolation options for START TRANSACTION, and I doubt > > they are going to think to look there because they think they are the > > same. That's why I think it is good to add those clauses to BEGIN > > WORK/TRANSACTION. > > > > Since BEGIN isn't standard, wouldn't it be time to redirect them on the > BEGIN manpage to the START TRANSACTION manpage and tell them there that > BEGIN does not support the full syntax of START TRANSACTION? Yea, we could do that, and if it was hard to add, we would, but it seems easier to just say BEGIN and START TRANSACTION are the same except the later is standard, rather than have the later have additional functionality too. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] BEGIN vs START TRANSACTION
Bruce Momjian <[EMAIL PROTECTED]> writes: > Jan Wieck wrote: >> Since BEGIN isn't standard, wouldn't it be time to redirect them on the >> BEGIN manpage to the START TRANSACTION manpage and tell them there that >> BEGIN does not support the full syntax of START TRANSACTION? > Yea, we could do that, and if it was hard to add, we would, but it seems > easier to just say BEGIN and START TRANSACTION are the same except the > later is standard, rather than have the later have additional > functionality too. IIRC, the code patch only added about two lines to gram.y. It seems a bit silly to add *more* lines of documentation to explain that the two statements aren't alike than it would take lines of code to make them work alike. regards, tom lane ---(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] [HACKERS] BEGIN vs START TRANSACTION
On Mon, Nov 10, 2003 at 11:23:20AM -0500, Tom Lane wrote: > IIRC, the code patch only added about two lines to gram.y. It seems a > bit silly to add *more* lines of documentation to explain that the two > statements aren't alike than it would take lines of code to make them > work alike. But maybe it would be useful to point out the difference; for example, users will get confused if they try to start a subtransaction inside a plpgsql function using BEGIN. -- Alvaro Herrera () "El miedo atento y previsor es la madre de la seguridad" (E. Burke) ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] borland builder 5 postgresql-7.4RC1
Good morning I'm trying to compile postgresql-7.4RC1 with borlad builder 6, as far as i understand i can only complie the client library and not the entire projecat, but i only neeed the libpq in order to migrate a previuous linux software to windows (sigh) I typed E:\postgres\postgresql-7.4RC1\postgresql-7.4RC1\src>make -f bcc32.mak and after a while a receive Warning: 'win32' not found in library Warning: 'getaddrinfo' not found in library Warning: 'inet_aton' not found in library Warning: 'crypt' not found in library Warning: 'path' not found in library Warning: 'dllist' not found in library Warning: 'md5' not found in library Warning: 'ip' not found in library Warning: 'fe-auth' not found in library Warning: 'fe-protocol2' not found in library Warning: 'fe-protocol3' not found in library Warning: 'fe-connect' not found in library Warning: 'fe-exec' not found in library Warning: 'fe-lobj' not found in library Warning: 'fe-misc' not found in library Warning: public '_pqFlush' in module 'fe-misc' clashes with prior module 'fe-exec' Warning: 'fe-print' not found in library Warning: 'fe-secure' not found in library Warning: 'pqexpbuffer' not found in library Warning: 'wchar' not found in library Warning: 'encnames' not found in library Warning: '' not found in library Warning: '.OBJ' file not found bcc32.exe -o".\Release\libpqdll" -I\include;..\..\include -WD -c -DFRONT END;NDEBUG;WIN32;_WINDOWS;HAVE_VSNPRINTF;HAVE_STRDUP; -tWM -a8 -X -w-use -w-pa r -w-pia -w-csu -w-aus -w-ccc -O -Oi -OS -DNDEBUG .\libpqdll.c Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland .\libpqdll.c: brcc32.exe -l 0x409 -i\include -fo".\Release\libpq.res" libpq.rc Borland Resource Compiler Version 5.40 Copyright (c) 1990, 1999 Inprise Corporation. All rights reserved. Error libpq.rc 1 11: Cannot open file: winver.h ** error 20018 ** deleting ".\Release\libpq.res" ** error 1 ** deleting ALL any idea? thx mirco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] "make check" improvement for cygwin
Jason Tishler wrote: > Peter, > > On Mon, Nov 10, 2003 at 03:48:07PM +0100, Peter Eisentraut wrote: > > Jason Tishler writes: > > > > > ! 1. Set your path to use the Cygwin bin directory before the Windows > > > > > ! utilities. Cygwin sort must be used in preference to Windows sort.exe. > > > > > > Is the above needed during runtime too? > > > > Can anyone see *any* use of "sort" that would warrant the above step? > > Not in practice. I just dragged it along because it was in older > versions of the FAQ. Would someone send a patch to modify the MSWIN FAQ, if required? -- 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 7: don't forget to increase your free space map settings
Re: [PATCHES] $PostgreSQL$ header -- Post 7.4 Release
Rod Taylor <[EMAIL PROTECTED]> writes: > In src/backend/utils/adt/inet_net_ntop.c and > src/backend/utils/adt/inet_net_pton.c it would appear that the $Id$ tag > is assigned to a variable (rcsid). ... which is never referenced AFAICT, even if the necessary preprocessor definitions are set so that it is seen by the compiler in the first place. Is there a reason not to remove this code from both files? -Neil ---(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] $PostgreSQL$ header -- Post 7.4 Release
Neil Conway wrote: > Rod Taylor <[EMAIL PROTECTED]> writes: > > In src/backend/utils/adt/inet_net_ntop.c and > > src/backend/utils/adt/inet_net_pton.c it would appear that the $Id$ tag > > is assigned to a variable (rcsid). > > ... which is never referenced AFAICT, even if the necessary > preprocessor definitions are set so that it is seen by the compiler in > the first place. Is there a reason not to remove this code from both > files? OK, removed with attached patch. (CVS will update the file name.) It is a BSD source code style that isn't used by our code. -- 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: src/backend/utils/adt/inet_net_ntop.c === RCS file: /cvsroot/pgsql-server/src/backend/utils/adt/inet_net_ntop.c,v retrieving revision 1.16 diff -c -c -r1.16 inet_net_ntop.c *** src/backend/utils/adt/inet_net_ntop.c 4 Aug 2003 00:43:25 - 1.16 --- src/backend/utils/adt/inet_net_ntop.c 10 Nov 2003 19:37:34 - *** *** 13,23 * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. */ - - #if defined(LIBC_SCCS) && !defined(lint) - static const char rcsid[] = "$Id: inet_net_ntop.c,v 1.16 2003/08/04 00:43:25 momjian Exp $"; - #endif #include "postgres.h" --- 13,21 * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. + * + * $Header: /cvsroot/pgsql-server/src/backend/utils/adt/int.c,v 1.57 2003/08/04 02:40:05 momjian Exp $ */ #include "postgres.h" Index: src/backend/utils/adt/inet_net_pton.c === RCS file: /cvsroot/pgsql-server/src/backend/utils/adt/inet_net_pton.c,v retrieving revision 1.16 diff -c -c -r1.16 inet_net_pton.c *** src/backend/utils/adt/inet_net_pton.c 4 Aug 2003 00:43:25 - 1.16 --- src/backend/utils/adt/inet_net_pton.c 10 Nov 2003 19:37:34 - *** *** 13,23 * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. */ - - #if defined(LIBC_SCCS) && !defined(lint) - static const char rcsid[] = "$Id: inet_net_pton.c,v 1.16 2003/08/04 00:43:25 momjian Exp $"; - #endif #include "postgres.h" --- 13,21 * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. + * + * $Header: /cvsroot/pgsql-server/src/backend/utils/adt/int.c,v 1.57 2003/08/04 02:40:05 momjian Exp $ */ #include "postgres.h" ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] initdb in C
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 [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] [HACKERS] Proposal: psql force prompting on notty
This is an unusual one. The OS isn't handling things properly, and we
have to work around that. Can you get a Win32 user to test psql with
this patch to make sure it actually fixes the problem and behaves as
expected? If you want me to produce a psql binary, I can do that.
Thanks.
---
Michael Mauger wrote:
> I'm the maintainer of sql.el in GNU Emacs. On both the Mac OS X
> and the Windows/Cygwin platform we've had reports that psql run
> under Emacs does not issue a prompt for commands.
>
> I did a little research and it appears that the cause is that
> pset.notty is being set to false because stdin/stdout are not
> a tty (pgsql-server/src/bin/psql/startup.c). I'd like to
> propose that an option be added to the psql command line to
> override the detection of the tty and force the prompting for
> commands on stdin.
>
> I believe the attached patch should add the option -I to psql
> and force the prompt to appear as if it were an interactive
> session regardless of the state of stdin/stdout. I do not
> have a configuration available to properly test this however.
>
> Please be sure to include me in any replies since I do not
> subscribe to this list. TIA.
>
> -- Michael
>
> __
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
Content-Description: interactive.diff
> --- pgsql-server/src/bin/psql/startup.c 29 Sep 2003 18:21:33 - 1.80
> +++ pgsql-server/src/bin/psql/startup.c 01 Nov 2003 06:10:42 -
> @@ -322,6 +322,7 @@
> {"field-separator", required_argument, NULL, 'F'},
> {"host", required_argument, NULL, 'h'},
> {"html", no_argument, NULL, 'H'},
> + {"interactive", no_argument, NULL, 'I'},
> {"list", no_argument, NULL, 'l'},
> {"no-readline", no_argument, NULL, 'n'},
> {"output", required_argument, NULL, 'o'},
> @@ -352,7 +353,7 @@
>
> memset(options, 0, sizeof *options);
>
> - while ((c = getopt_long(argc, argv,
> "aAc:d:eEf:F:h:Hlno:p:P:qR:sStT:uU:v:VWxX?",
> + while ((c = getopt_long(argc, argv,
> "aAc:d:eEf:F:h:HlMno:p:P:qR:sStT:uU:v:VWxX?",
> long_options, &optindex)) !=
> -1)
> {
> switch (c)
> @@ -395,7 +396,10 @@
> case 'H':
> pset.popt.topt.format = PRINT_HTML;
> break;
> + case 'I':
> + pset.notty = 0;
> + break;
> case 'l':
> options->action = ACT_LIST_DB;
> break;
> --- pgsql-server/src/bin/psql/help.c 02 Oct 2003 06:39:31 - 1.81
> +++ pgsql-server/src/bin/psql/help.c 01 Nov 2003 06:29:50 -
> @@ -103,6 +103,7 @@
> puts(_(" -a echo all input from script"));
> puts(_(" -e echo commands sent to server"));
> puts(_(" -E display queries that internal commands generate"));
> + puts(_(" -I force interactive prompting for input"));
> puts(_(" -q run quietly (no messages, only query output)"));
> puts(_(" -o FILENAME send query results to file (or |pipe)"));
> puts(_(" -n disable enhanced command line editing (readline)"));
>
> ---(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 7: don't forget to increase your free space map settings
Re: [PATCHES] "make check" improvement for cygwin
! 1. Set your path to use the Cygwin bin directory before the Windows ! utilities. Cygwin sort must be used in preference to Windows sort.exe. Is the above needed during runtime too? Can anyone see *any* use of "sort" that would warrant the above step? Not in practice. I just dragged it along because it was in older versions of the FAQ. Would someone send a patch to modify the MSWIN FAQ, if required? I'll do it shortly. Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] "make check" improvement for cygwin
Here's some improvements. I just ended up referring people to Jason's website for install as service, because it's a quite a long and complex process. Is that README included with the cygwin package, Jason? Because I couldn't find it in mine...? Chris Bruce Momjian wrote: Jason Tishler wrote: Peter, On Mon, Nov 10, 2003 at 03:48:07PM +0100, Peter Eisentraut wrote: Jason Tishler writes: ! 1. Set your path to use the Cygwin bin directory before the Windows ! utilities. Cygwin sort must be used in preference to Windows sort.exe. Is the above needed during runtime too? Can anyone see *any* use of "sort" that would warrant the above step? Not in practice. I just dragged it along because it was in older versions of the FAQ. Would someone send a patch to modify the MSWIN FAQ, if required? Index: doc/FAQ_MSWIN === RCS file: /projects/cvsroot/pgsql-server/doc/FAQ_MSWIN,v retrieving revision 1.16 diff -c -r1.16 FAQ_MSWIN *** doc/FAQ_MSWIN 9 Nov 2003 03:47:51 - 1.16 --- doc/FAQ_MSWIN 11 Nov 2003 01:59:40 - *** *** 1,9 How to install PostgreSQL on Windows $Date: 2003/11/09 03:47:51 $ ! 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 --- 1,10 How to install PostgreSQL on Windows + $Date: 2003/11/09 03:47:51 $ ! PostgreSQL requires the appropriate subset of Cygwin DLLs 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 *** *** 16,22 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 --- 17,24 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. Answer the other installer questions ! appropriately for your configuration. When you come to the point of choosing which packages to install, expand the 'Database' section and click 'Skip' next to PostgreSQL *** *** 24,34 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). --- 26,35 Cygwin. 3. Once the download and install process is complete, open a Cygwin ! shell and do the following for a basic installation: ! 3a. Start ipc-daemon2 for shared memory support. To do this, ! enter the command "ipc-daemon2 &". This program needs to be running anytime you start the PostgreSQL server (postmaster) or initialize a database (initdb). *** *** 52,57 --- 53,64 4. You are now running a PostgreSQL server on your Windows machine. + 5. It is possible to install ipc-daemon2 and the postmaster as + Windows NT services. For information on how to do this, please + refer to one of the README documents here: + + http://www.tishler.net/jason/software/postgresql/ + Building from source *** *** 59,65 PostgreSQL from source: 1. Set your path to use the Cygwin bin directory before the Windows ! utilities. Cygwin sort must be used in preference to Windows sort.exe. 2. Proceed according to the INSTALL file (i.e., ./configure; make; etc.) noting the following Cygwin specific differences: --- 66,72 PostgreSQL from source: 1. Set your path to use the Cygwin bin directory before the Windows ! utilities. This will help prevent problems with compilation. 2. Proceed according to the INSTALL file (i.e., ./configure; make; etc.) noting the following Cygwin specific differences: ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [pgsql-hackers-win32] Other Win32 TODO items?
Claudio Natoli wrote:
> * stat() + extension differences
> - execute bits returned by stat are based on file extension under
> Win32
> - therefore, binaries'll need to have .exe extension (ie. no symlink
> for postmaster), and the calls to stat'll have to append ".exe".
OK, the attached, applied patch takes care of these issues.
--
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: src/backend/Makefile
===
RCS file: /cvsroot/pgsql-server/src/backend/Makefile,v
retrieving revision 1.95
diff -c -c -r1.95 Makefile
*** src/backend/Makefile21 Mar 2003 17:18:34 - 1.95
--- src/backend/Makefile11 Nov 2003 03:46:20 -
***
*** 138,145
install-bin: postgres $(POSTGRES_IMP) installdirs
$(INSTALL_PROGRAM) postgres$(X) $(DESTDIR)$(bindir)/postgres$(X)
! @rm -f $(DESTDIR)$(bindir)/postmaster
! ln -s postgres$(X) $(DESTDIR)$(bindir)/postmaster
ifeq ($(MAKE_EXPORTS), true)
$(INSTALL_DATA) $(POSTGRES_IMP) $(DESTDIR)$(pkglibdir)/$(POSTGRES_IMP)
endif
--- 138,149
install-bin: postgres $(POSTGRES_IMP) installdirs
$(INSTALL_PROGRAM) postgres$(X) $(DESTDIR)$(bindir)/postgres$(X)
! ifneq ($(PORTNAME), win32)
! @rm -f $(DESTDIR)$(bindir)/postmaster$(X)
! ln -s postgres$(X) $(DESTDIR)$(bindir)/postmaster$(X)
! else
! $(INSTALL_PROGRAM) postgres$(X) $(DESTDIR)$(bindir)/postmaster$(X)
! endif
ifeq ($(MAKE_EXPORTS), true)
$(INSTALL_DATA) $(POSTGRES_IMP) $(DESTDIR)$(pkglibdir)/$(POSTGRES_IMP)
endif
Index: src/backend/utils/init/findbe.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/init/findbe.c,v
retrieving revision 1.37
diff -c -c -r1.37 findbe.c
*** src/backend/utils/init/findbe.c 4 Aug 2003 02:40:06 - 1.37
--- src/backend/utils/init/findbe.c 11 Nov 2003 03:46:21 -
***
*** 49,59
--- 49,70
uid_t euid;
struct group *gp;
struct passwd *pwp;
+ charpath_exe[MAXPGPATH + 2 + strlen(".exe")];
#endif
int i;
int is_r = 0;
int is_x = 0;
int in_grp = 0;
+
+ #ifdef WIN32
+ /* Win32 requires a .exe suffix for stat() */
+ if (strlen(path) >= 4 && strcmp(path + strlen(path) - strlen(".exe"), ".exe")
!= 0)
+ {
+ strcpy(path_exe, path);
+ strcat(path_exe, ".exe");
+ path = path_exe;
+ }
+ #endif
/*
* Ensure that the file exists and is a regular file.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] sigpipe handling
Sorry, but this just seems overdesigned. I liked Tom's suggestion:
> One possibility that comes to mind is simply to test whether the SIGPIPE
> handler is already SIG_IGN before we munge it. Ideally we'd do that
> once when the conn object is created, but even if it had to be done more
> often, it might still be a net win.
Can't we just check the SIGPIPE handler when the first connection is
opened, and if it is the default, we can set it to ignore --- if not, we
use our special disable code around each send call, and we document it
in the libpq manual, and mention it in the release notes. If someone
wants to muddle with SIGPIPE after the first connection, let them set
the SIGPIPE to point to a dummy function before making the first
connection --- that seems like a clear-enough API for the few folks who
want to play with this.
---
Manfred Spraul wrote:
> 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.pgbench10 Jun 2003 09:07:15 - 1.9
> --- contrib/pgbench/README.pgbench8 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
>
>
>
> +
> +
> PQsetsighandling
Re: [PATCHES] SIGPIPE handling, take two.
I think this is the patch I like. It does the auto-detect handling as I
hoped. I will just do the doc updates to mention it.
My only issue is that this is per-connection, while I think you have to
create a global variable that defaults to false, and on first connect,
check, and not after. Based on the code below, a second connection
would have the SIGPIPE signal set to SIG_IGN, not SIG_DEF, and you
would be back to setting SIG_IGN around each send, even though it was
already set.
Are others OK with this too?
---
Manfred Spraul wrote:
> pqsecure_write tries to catch SIGPIPE signals generated by network
> disconnects by setting the signal handler to SIG_IGN. The current
> approach causes several problems:
> - it always sets SA_RESTART when it restores the old handler.
> - it's not reliable for multi threaded apps, because another thread
> could change the signal handler inbetween.
> - it's slow, because after setting a signal handler to SIG_IGN the
> kernel must enumerate all threads and clear all pending signals (at
> least FreeBSD-5.1 and linux-2.6 do that. Earlier linux kernels don't -
> their signal handling is known to be broken for multithreaded apps).
>
> Initially I proposed a new option for PQconnectdb, but Tom didn't like
> that. The attached patch autodetects if it should set the signal
> handler, Tom proposed that. The code doesn't try to check if the signal
> is "handled" by blocking it, because I haven't figured out how to check
> that: sigprocmask is undefined for multithreaded apps and calling
> pthread_sigmask would force every libpq user to link against libpthread.
>
> --
> Manfred
> ? src/interfaces/libpq/libpq.so.3.1
> Index: src/interfaces/libpq/fe-connect.c
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
> retrieving revision 1.263
> diff -c -r1.263 fe-connect.c
> *** src/interfaces/libpq/fe-connect.c 18 Oct 2003 05:02:06 - 1.263
> --- src/interfaces/libpq/fe-connect.c 2 Nov 2003 18:29:40 -
> ***
> *** 41,46
> --- 41,47
> #include
> #endif
> #include
> + #include
> #endif
>
> #include "libpq/ip.h"
> ***
> *** 951,956
> --- 952,983
> else if (conn->sslmode[0] == 'a') /* "allow" */
> conn->wait_ssl_try = true;
> #endif
> + /*
> + * Autodetect SIGPIPE signal handling:
> + * The default action per Unix spec is kill current process and
> + * that's not acceptable. If the current setting is not the default,
> + * then assume that the caller knows what he's doing and leave the
> + * signal handler unchanged. Otherwise set the signal handler to
> + * SIG_IGN around each send() syscall. Unfortunately this is both
> + * unreliable and slow for multithreaded apps.
> + */
> + conn->do_sigaction = true;
> + #if !defined(HAVE_POSIX_SIGNALS)
> + {
> + pqsigfunc old;
> + old = signal(SIGPIPE, SIG_IGN);
> + if (old != SIG_DFL)
> + conn->do_sigaction = false;
> + signal(SIGPIPE, old);
> + }
> + #else
> + {
> + struct sigaction oact;
> +
> + if (sigaction(SIGPIPE, NULL, &oact) == 0 && oact.sa_handler != SIG_DFL)
> + conn->do_sigaction = false;
> + }
> + #endif /* !HAVE_POSIX_SIGNALS */
>
> /*
>* Set up to try to connect, with protocol 3.0 as the first attempt.
> Index: src/interfaces/libpq/fe-secure.c
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-secure.c,v
> retrieving revision 1.32
> diff -c -r1.32 fe-secure.c
> *** src/interfaces/libpq/fe-secure.c 29 Sep 2003 16:38:04 - 1.32
> --- src/interfaces/libpq/fe-secure.c 2 Nov 2003 18:29:41 -
> ***
> *** 348,354
> ssize_t n;
>
> #ifndef WIN32
> ! pqsigfunc oldsighandler = pqsignal(SIGPIPE, SIG_IGN);
> #endif
>
> #ifdef USE_SSL
> --- 348,357
> ssize_t n;
>
> #ifndef WIN32
> ! pqsigfunc oldsighandler = NULL;
> !
> ! if (conn->do_sigaction)
> ! oldsighandler = pqsignal(SIGPIPE, SIG_IGN);
> #endif
>
> #ifdef USE_SSL
> ***
> *** 408,414
> n = send(conn->sock, ptr, len, 0);
>
> #ifndef WIN32
> ! pqsignal(SIGPIPE, oldsighandler);
> #endif
>
> return n;
> --- 411,418
> n = send(conn->sock, ptr, len, 0);
>
> #ifndef WIN32
> ! if (conn->do_sigaction)
> ! pqsignal(SIGPIPE, oldsighandler);
> #endif
>
> return n;
> Index: src/interfaces/libpq/libpq-int.h
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/in
