From markwkm at gmail.com Mon Jan 14 05:36:21 2008 From: markwkm at gmail.com (Mark Wong) Date: Sun, 13 Jan 2008 21:36:21 -0800 Subject: [ptop-hackers] PostgreSQL top (ptop) 3.6.1 Beta 2 -- compile problem In-Reply-To: <8B319E5A30FF4A48BE7EEAAF609DB233015E3101@COMAIL01.digitalglobe.com> References: <8B319E5A30FF4A48BE7EEAAF609DB233015E3101@COMAIL01.digitalglobe.com> Message-ID: <70c01d1d0801132136tfd8a5a8xca83b15d3825e773@mail.gmail.com> On Dec 20, 2007 3:05 AM, Gregory Williamson wrote: > > > > I asked our sysadmins to install this package and got back this: > > > got this error when I tried to compile it: > > > > gcc -DHAVE_CONFIG_H -I. -I. -Wall -g -I/apps/postgresql-8.2.5_64/ > > include -I/apps/postgresql-8.2.5_64/include -c -o ptop.o ptop.c > > In file included from ptop.c:61: > > port.h:337: error: conflicting types for `inet_aton' > > /usr/include/arpa/inet.h:74: error: previous declaration of `inet_aton' > > make: *** [ptop.o] Error 1 Sorry for the delay, took a while before I could get myself a debian system to try this on. Attached is a patch that should fix this particular problem. It will be included in the next beta. If you try it now, don't forget to run autoconf and autoheader (and make distclean) so that the configure script and the config.h.in gets updated. Also included in the patch is a new error that tells you when curses (or termcap) header files are missing. Regards, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: ptop-config-inet.patch Type: text/x-patch Size: 916 bytes Desc: not available Url : http://pgfoundry.org/pipermail/ptop-hackers/attachments/20080113/34dbab05/attachment.bin From Gregory.Williamson at digitalglobe.com Mon Jan 14 06:00:21 2008 From: Gregory.Williamson at digitalglobe.com (Gregory Williamson) Date: Sun, 13 Jan 2008 23:00:21 -0700 Subject: [ptop-hackers] PostgreSQL top (ptop) 3.6.1 Beta 2 -- compile problem References: <8B319E5A30FF4A48BE7EEAAF609DB233015E3101@COMAIL01.digitalglobe.com> <70c01d1d0801132136tfd8a5a8xca83b15d3825e773@mail.gmail.com> Message-ID: <8B319E5A30FF4A48BE7EEAAF609DB233015E31E0@COMAIL01.digitalglobe.com> Thanks ! I will pass this on to our sysadmins tomorrow and let you know what how it goes. Greg W. -----Original Message----- From: Mark Wong [mailto:markwkm at gmail.com] Sent: Sun 1/13/2008 10:36 PM To: Gregory Williamson Cc: ptop-hackers at pgfoundry.org Subject: Re: [ptop-hackers] PostgreSQL top (ptop) 3.6.1 Beta 2 -- compile problem On Dec 20, 2007 3:05 AM, Gregory Williamson wrote: > > > > I asked our sysadmins to install this package and got back this: > > > got this error when I tried to compile it: > > > > gcc -DHAVE_CONFIG_H -I. -I. -Wall -g -I/apps/postgresql-8.2.5_64/ > > include -I/apps/postgresql-8.2.5_64/include -c -o ptop.o ptop.c > > In file included from ptop.c:61: > > port.h:337: error: conflicting types for `inet_aton' > > /usr/include/arpa/inet.h:74: error: previous declaration of `inet_aton' > > make: *** [ptop.o] Error 1 Sorry for the delay, took a while before I could get myself a debian system to try this on. Attached is a patch that should fix this particular problem. It will be included in the next beta. If you try it now, don't forget to run autoconf and autoheader (and make distclean) so that the configure script and the config.h.in gets updated. Also included in the patch is a new error that tells you when curses (or termcap) header files are missing. Regards, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://pgfoundry.org/pipermail/ptop-hackers/attachments/20080113/5acc1910/attachment.html From markwkm at gmail.com Mon Jan 14 16:18:24 2008 From: markwkm at gmail.com (Mark Wong) Date: Mon, 14 Jan 2008 08:18:24 -0800 Subject: [ptop-hackers] compiling error In-Reply-To: References: Message-ID: <70c01d1d0801140818v25ad0367oe8fbe4051291f931@mail.gmail.com> On Dec 19, 2007 7:22 AM, Daniel Gr?f wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I'm running Suse Linux 9.1 and PostgreSQL 8.1. When I tried to > compile the binary I get the following error. > > gcc -DHAVE_CONFIG_H -I. -I. -Wall -g -I/usr/local/pgsql_81/include -I/ > usr/local/pgsql_81/include -c -o color.o color.c > gawk -f ./sigconv.awk /usr/include/bits/signum.h >sigdesc.h > gcc -DHAVE_CONFIG_H -I. -I. -Wall -g -I/usr/local/pgsql_81/include -I/ > usr/local/pgsql_81/include -c -o commands.o commands.c > gcc -DHAVE_CONFIG_H -I. -I. -Wall -g -I/usr/local/pgsql_81/include -I/ > usr/local/pgsql_81/include -c -o display.o display.c > gcc -DHAVE_CONFIG_H -I. -I. -Wall -g -I/usr/local/pgsql_81/include -I/ > usr/local/pgsql_81/include -c -o screen.o screen.c > gcc -DHAVE_CONFIG_H -I. -I. -Wall -g -I/usr/local/pgsql_81/include -I/ > usr/local/pgsql_81/include -c -o sprompt.o sprompt.c > gcc -DHAVE_CONFIG_H -I. -I. -Wall -g -I/usr/local/pgsql_81/include -I/ > usr/local/pgsql_81/include -c -o pg.o pg.c > gcc -DHAVE_CONFIG_H -I. -I. -Wall -g -I/usr/local/pgsql_81/include -I/ > usr/local/pgsql_81/include -c -o ptop.o ptop.c > In file included from ptop.c:61: > port.h:337: error: conflicting types for `inet_aton' > /usr/include/arpa/inet.h:74: error: previous declaration of `inet_aton' > make: *** [ptop.o] Fehler 1 > > Any ideas? I think I fixed this problem, which I tested on Debian 3.1. I mailed it out on the list to the person reporting the problem on Debian but I'll attach the patch again to make sure you at least see it, which will be included in the next beta release. If you try it now, don't forget to run 'make distclean', autoconf, autoheader to make sure the changes take effect. Regards, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: ptop-config-inet.patch Type: text/x-patch Size: 916 bytes Desc: not available Url : http://pgfoundry.org/pipermail/ptop-hackers/attachments/20080114/4322a815/attachment.bin From markwkm at gmail.com Thu Jan 17 05:46:24 2008 From: markwkm at gmail.com (Mark Wong) Date: Wed, 16 Jan 2008 21:46:24 -0800 Subject: [ptop-hackers] PostgreSQL top (ptop) 3.6.1 Beta 3 released Message-ID: <70c01d1d0801162146v78d5e4cal9589c1571b20b672@mail.gmail.com> I'm pleased to announce the third beta version of ptop. It is a utility that provides a display of top PostgreSQL processes and other database statistics. Changes in this release include: - Fixed build problems reported on Debian, SLES, and RHEL. - More documentation fixes of changing 'top' to 'ptop'. - Display actual database connection error message when there is a connection problem. - Use the same -p PORT, -U USER, and -d DBNAME command line options as other PostgreSQL programs. - Change unixtop's original -d to -x, and -U to -z. Download here: http://pgfoundry.org/frs/download.php/1567/ptop-3.6.1-beta3.tar.gz Screen shots here: http://ptop.projects.postgresql.org/screenshots/ Please send any comments or problems to ptop-hackers ( at ) pgfoundry ( dot ) org Regards, Mark From tommy.gildseth at usit.uio.no Tue Jan 29 11:44:01 2008 From: tommy.gildseth at usit.uio.no (Tommy Gildseth) Date: Tue, 29 Jan 2008 12:44:01 +0100 Subject: [ptop-hackers] [ANNOUNCE] PostgreSQL top (ptop) 3.6.1 Beta 3 released In-Reply-To: <70c01d1d0801281854o70ba8eabla4a6a08f1810a7f0@mail.gmail.com> References: <70c01d1d0801281854o70ba8eabla4a6a08f1810a7f0@mail.gmail.com> Message-ID: <479F1181.5040600@usit.uio.no> Mark Wong wrote: > I'm pleased to announce the third beta version of ptop. It is a > utility that provides a display of top PostgreSQL processes and other > database statistics. > > Please send any comments or problems to ptop-hackers ( at ) pgfoundry > ( dot ) org Hi! I was wondering if it would be possible to add an option for specifying the location of the socket-file. In our setup, we run multiple clusters on the same physical clusters, as well as keeping the socket files in non-standard locations. This makes it unpractical to use the PGHOST env variable. In addition, I noticed that if you did not specify a database name, it would not be possible to specify a username or password, as it would pass f.ex username=foo as the database name. I've attached a patch with these changes, if you find this usefull. -- Tommy Gildseth -------------- next part -------------- A non-text attachment was scrubbed... Name: ptop.patch Type: text/x-patch Size: 1262 bytes Desc: not available Url : http://pgfoundry.org/pipermail/ptop-hackers/attachments/20080129/f1ffdf65/attachment-0001.bin From markwkm at gmail.com Tue Jan 29 16:46:15 2008 From: markwkm at gmail.com (Mark Wong) Date: Tue, 29 Jan 2008 08:46:15 -0800 Subject: [ptop-hackers] [ANNOUNCE] PostgreSQL top (ptop) 3.6.1 Beta 3 released In-Reply-To: <479F1181.5040600@usit.uio.no> References: <70c01d1d0801281854o70ba8eabla4a6a08f1810a7f0@mail.gmail.com> <479F1181.5040600@usit.uio.no> Message-ID: <20080129084615.66466484.markwkm@gmail.com> On Tue, 29 Jan 2008 12:44:01 +0100 Tommy Gildseth wrote: > Mark Wong wrote: > > I'm pleased to announce the third beta version of ptop. It is a > > utility that provides a display of top PostgreSQL processes and other > > database statistics. > > > > Please send any comments or problems to ptop-hackers ( at ) pgfoundry > > ( dot ) org > > Hi! > > I was wondering if it would be possible to add an option for specifying > the location of the socket-file. In our setup, we run multiple clusters > on the same physical clusters, as well as keeping the socket files in > non-standard locations. This makes it unpractical to use the PGHOST env > variable. > In addition, I noticed that if you did not specify a database name, it > would not be possible to specify a username or password, as it would > pass f.ex username=foo as the database name. > I've attached a patch with these changes, if you find this usefull. Hi Tommy, Thanks for the patch! Regarding the database name, I believe what I had done is when unspecified it will default to DBUSER environment or the username. I sort of forget the order of preference here. Otherwise it will use what is specified. But maybe I screwed that up so I'll take a closer look. Regards, Mark From tommy.gildseth at usit.uio.no Thu Jan 31 12:42:33 2008 From: tommy.gildseth at usit.uio.no (Tommy Gildseth) Date: Thu, 31 Jan 2008 13:42:33 +0100 Subject: [ptop-hackers] [ANNOUNCE] PostgreSQL top (ptop) 3.6.1 Beta 3 released In-Reply-To: <20080129084615.66466484.markwkm@gmail.com> References: <70c01d1d0801281854o70ba8eabla4a6a08f1810a7f0@mail.gmail.com> <479F1181.5040600@usit.uio.no> <20080129084615.66466484.markwkm@gmail.com> Message-ID: <47A1C239.3090604@usit.uio.no> Mark Wong wrote: > On Tue, 29 Jan 2008 12:44:01 +0100 > Tommy Gildseth wrote >> Hi! >> >> In addition, I noticed that if you did not specify a database name, it >> would not be possible to specify a username or password, as it would >> pass f.ex username=foo as the database name. >> I've attached a patch with these changes, if you find this usefull. >> > > Hi Tommy, > > Thanks for the patch! Regarding the database name, I believe what I > had done is when unspecified it will default to DBUSER environment or > the username. I sort of forget the order of preference here. Otherwise > it will use what is specified. But maybe I screwed that up so I'll > take a closer look. Yes, the default behaviour when database name isn't specfied in the call to PQconnectdb is to assume the same as the user name: PQconnectdb: dbname The database name. Defaults to be the same as the user name. The problem I think is that in ptop.c, you construct the connectionstring like this: sprintf(conninfo, "port=%d dbname=%s %s %s %s", dbport, dbname, socket, dbusername, password); meaning that if the dbname variable is empty, it will take one of the following arguments(ie. user=foo) as the database name. I couldn't find anywhere that any other value than "" or sprintf(dbname, "%s", optarg); is being assigned to dbname, so unless you explicitly supply an argument -U, you'll end up with a connectionstring like "port=5432 dbname=" I'm guessing that if you don't specify a dbname, username or password (and now, socket), this works just fine, but as soon as you add f.ex a username after that, you get "port=5432 dbname= user=foo", which I'm guessing isn't quite what you intended?|||| -- Tommy Gildseth From markwkm at gmail.com Thu Jan 31 15:12:28 2008 From: markwkm at gmail.com (Mark Wong) Date: Thu, 31 Jan 2008 07:12:28 -0800 Subject: [ptop-hackers] [ANNOUNCE] PostgreSQL top (ptop) 3.6.1 Beta 3 released In-Reply-To: <47A1C239.3090604@usit.uio.no> References: <70c01d1d0801281854o70ba8eabla4a6a08f1810a7f0@mail.gmail.com> <479F1181.5040600@usit.uio.no> <20080129084615.66466484.markwkm@gmail.com> <47A1C239.3090604@usit.uio.no> Message-ID: <70c01d1d0801310712i401550e8n2b3271b22afc7b7c@mail.gmail.com> On Jan 31, 2008 4:42 AM, Tommy Gildseth wrote: > Mark Wong wrote: > > On Tue, 29 Jan 2008 12:44:01 +0100 > > Tommy Gildseth wrote > >> Hi! > >> > >> In addition, I noticed that if you did not specify a database name, it > >> would not be possible to specify a username or password, as it would > >> pass f.ex username=foo as the database name. > >> I've attached a patch with these changes, if you find this usefull. > >> > > > > Hi Tommy, > > > > Thanks for the patch! Regarding the database name, I believe what I > > had done is when unspecified it will default to DBUSER environment or > > the username. I sort of forget the order of preference here. Otherwise > > it will use what is specified. But maybe I screwed that up so I'll > > take a closer look. > Yes, the default behaviour when database name isn't specfied in the call > to PQconnectdb is to assume the same as the user name: > PQconnectdb: > dbname > The database name. Defaults to be the same as the user name. > > The problem I think is that in ptop.c, you construct the > connectionstring like this: > sprintf(conninfo, "port=%d dbname=%s %s %s %s", dbport, > dbname, socket, dbusername, password); > > meaning that if the dbname variable is empty, it will take one of the > following arguments(ie. user=foo) as the database name. I couldn't find > anywhere that any other value than "" or sprintf(dbname, "%s", optarg); > is being assigned to dbname, so unless you explicitly supply an argument > -U, you'll end up with a connectionstring like "port=5432 dbname=" > > I'm guessing that if you don't specify a dbname, username or password > (and now, socket), this works just fine, but as soon as you add f.ex a > username after that, you get "port=5432 dbname= user=foo", which I'm > guessing isn't quite what you intended?|||| Right, but having "dbname=" does behave as you just described, at least on linux. :) I don't remember if I tried it where I omit dbname completely. Regards, Mark