Thread: R: Re: adminpack installation problem
Dear all, i have i question about server status tool of pgadminIII. I installed pgadminIII version 1.12.3 and in my server status tool there isn't Application tab. There are PID, Database,etc.. but no Application tab. I think it is usefull to understand "who" works in. Do you have any idea? Thanks Francesco Boccacci >----Messaggio originale---- >Da: frenchm@cromwell.co.uk >Data: 06/07/2011 13.29 >A: <francescoboccacci@libero.it>, <pgsql-admin@postgresql.org> >Ogg: Re: [ADMIN] adminpack installation problem > >Hi > >You need to ensure you install into the database you specified as your maintenance database in pgAdmin. > >If you connect to a database called "live" but use "template1" as your maintenance database, then you will need to install into "template1". > >psql -U postgres template1 -f /usr/share/postgresql/8.4/contrib/adminpack > >Cheers > > >-----Original Message----- >From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql. org] On Behalf Of francescoboccacci@libero.it >Sent: 06 July 2011 09:20 >To: pgsql-admin@postgresql.org >Subject: [ADMIN] adminpack installation problem > >Dear all, >i have a question for you. I'd like to install adminpack functionality to my >pgadminIII. I use pgaminIII v1.10 and with it i connect to my server where i >installed a cluster of database. I read some documentations but i don't >understand how can install the package. I found in my server >/usr/share/postgresql/8.4/contrib/adminpack.sql. >How can install it? i have to run this sql in all my database cluster like >this: > >psql -U postgres DATABASENAME < /usr/share/postgresql/8.4/contrib/adminpack. >sql > >Thanks > >Francesco Boccacci > >-- >Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-admin > >___________________________________________________ > >This email is intended for the named recipient. The information contained >in it is confidential. You should not copy it for any purposes, nor >disclose its contents to any other party. If you received this email >in error, please notify the sender immediately via email, and delete it from >your computer. > >Any views or opinions presented are solely those of the author and do not >necessarily represent those of the company. > >PCI Compliancy: Please note, we do not send or wish to receive banking, credit >or debit card information by email or any other form of communication. > >Please try our new on-line ordering system at http://www.cromwell.co.uk/ice > >Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive >Wigston, Leicester LE18 1AT. Tel 0116 2888000 >Registered in England and Wales, Reg No 00986161 >VAT GB 115 5713 87 900 >__________________________________________________ > > >-- >Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-admin >
Dear Francesco, On Thu, 7 Jul 2011 10:29:10 +0200 (CEST), "francescoboccacci@libero.it" <francescoboccacci@libero.it> wrote: > tab. There are PID, Database,etc.. but no Application tab. I think it > is > usefull to understand "who" works in. application_name has been added in PostgreSQL 9.0. Your server is 8.4. Ciao, Gabriele -- Gabriele Bartolini - 2ndQuadrant Italia PostgreSQL Training, Services and Support Gabriele.Bartolini@2ndQuadrant.it - www.2ndQuadrant.it
Francesco, This will only show on databases that have support for Application_name. I believe this is version 9 onwards. My 8.4 Databases Don't show it. My 8.1 databases error with:"FATAL: unrecognized configuration parameter "application_name", My 9.0 databases show it. cheers -----Original Message----- From: francescoboccacci@libero.it [mailto:francescoboccacci@libero.it] Sent: 07 July 2011 09:29 To: French, Martin; pgsql-admin@postgresql.org Subject: R: Re: [ADMIN] adminpack installation problem Dear all, i have i question about server status tool of pgadminIII. I installed pgadminIII version 1.12.3 and in my server status tool there isn't Application tab. There are PID, Database,etc.. but no Application tab. I think it is usefull to understand "who" works in. Do you have any idea? Thanks Francesco Boccacci >----Messaggio originale---- >Da: frenchm@cromwell.co.uk >Data: 06/07/2011 13.29 >A: <francescoboccacci@libero.it>, <pgsql-admin@postgresql.org> >Ogg: Re: [ADMIN] adminpack installation problem > >Hi > >You need to ensure you install into the database you specified as your maintenance database in pgAdmin. > >If you connect to a database called "live" but use "template1" as your maintenance database, then you will need to install into "template1". > >psql -U postgres template1 -f /usr/share/postgresql/8.4/contrib/adminpack > >Cheers > > >-----Original Message----- >From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql. org] On Behalf Of francescoboccacci@libero.it >Sent: 06 July 2011 09:20 >To: pgsql-admin@postgresql.org >Subject: [ADMIN] adminpack installation problem > >Dear all, >i have a question for you. I'd like to install adminpack functionality to my >pgadminIII. I use pgaminIII v1.10 and with it i connect to my server where i >installed a cluster of database. I read some documentations but i don't >understand how can install the package. I found in my server >/usr/share/postgresql/8.4/contrib/adminpack.sql. >How can install it? i have to run this sql in all my database cluster like >this: > >psql -U postgres DATABASENAME < /usr/share/postgresql/8.4/contrib/adminpack. >sql > >Thanks > >Francesco Boccacci > >-- >Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-admin > >___________________________________________________ > >This email is intended for the named recipient. The information contained >in it is confidential. You should not copy it for any purposes, nor >disclose its contents to any other party. If you received this email >in error, please notify the sender immediately via email, and delete it from >your computer. > >Any views or opinions presented are solely those of the author and do not >necessarily represent those of the company. > >PCI Compliancy: Please note, we do not send or wish to receive banking, credit >or debit card information by email or any other form of communication. > >Please try our new on-line ordering system at http://www.cromwell.co.uk/ice > >Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive >Wigston, Leicester LE18 1AT. Tel 0116 2888000 >Registered in England and Wales, Reg No 00986161 >VAT GB 115 5713 87 900 >__________________________________________________ > > >-- >Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-admin > ___________________________________________________ This email is intended for the named recipient. The information contained in it is confidential. You should not copy it for any purposes, nor disclose its contents to any other party. If you received this email in error, please notify the sender immediately via email, and delete it from your computer. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company. PCI Compliancy: Please note, we do not send or wish to receive banking, credit or debit card information by email or any other form of communication. Please try our new on-line ordering system at http://www.cromwell.co.uk/ice Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive Wigston, Leicester LE18 1AT. Tel 0116 2888000 Registered in England and Wales, Reg No 00986161 VAT GB 115 5713 87 900 __________________________________________________
Hi, I am building a site at the moment using the standard SQL system, I have just read through your posts and before I get too far need to know if it would be more beneficial to change the database accross? The online system is as below: Any help is most appreciated! http://www.specialisedtools.co.uk Kind Regards Paul Morris Specialised Tools & Equipment Ltd Tel: 01709 366882 e-mail: paul@specialisedtools.co.uk web: http://www.specialisedtools.co.uk -- View this message in context: http://postgresql.1045698.n5.nabble.com/R-Re-ADMIN-adminpack-installation-problem-tp4560325p4708835.html Sent from the PostgreSQL - admin mailing list archive at Nabble.com.
On 18/08/2011 12:02 AM, specialisedtools wrote: > Hi, I am building a site at the moment using the standard SQL system, I have > just read through your posts and before I get too far need to know if it > would be more beneficial to change the database accross? > > The online system is as below: Any help is most appreciated! > > http://www.specialisedtools.co.uk > What's the "standard SQL" system? What problem are you having that you want to solve? Try explaining in more detail. What are you trying to achieve? What is the current state of your effort? What have you already tried? -- Craig Ringer
We had to temporarily assign two IP addresses to our servers. After doing so and rebooting, Londiste will start, but itjust sits there doing nothing. The logfile has zero bytes, and it doesn't seem to connect to either the master or theslave database. We reconfigured Postgres to listen on both addresses, but the /etc/hosts tables still point to the original addresses (thatis, the second IP address shouldn't matter). But I can connect to Postgres on either IP address on all servers. All other Postgres applications work. I can use psql, and our Perl DBI and PHP applications all work with no problems. When I invoke "londiste.py --verbose ...", the log file says: 2011-08018 16:35:47,250 22074 DEBUG Attaching And that's all. Nothing more ever happens. Help? Thanks! Craig
On Fri, Aug 19, 2011 at 2:44 AM, Craig James <craig_james@emolecules.com> wrote: > We had to temporarily assign two IP addresses to our servers. After doing > so and rebooting, Londiste will start, but it just sits there doing nothing. > The logfile has zero bytes, and it doesn't seem to connect to either the > master or the slave database. > > We reconfigured Postgres to listen on both addresses, but the /etc/hosts > tables still point to the original addresses (that is, the second IP address > shouldn't matter). But I can connect to Postgres on either IP address on > all servers. > > All other Postgres applications work. I can use psql, and our Perl DBI and > PHP applications all work with no problems. > > When I invoke "londiste.py --verbose ...", the log file says: > > 2011-08018 16:35:47,250 22074 DEBUG Attaching > > And that's all. Nothing more ever happens. > > Help? Thanks! Does the exact connect string you use in londiste config work with psql? Like so: $ psql -d 'connstr' -- marko
On 8/19/11 1:40 AM, Marko Kreen wrote: > On Fri, Aug 19, 2011 at 2:44 AM, Craig James<craig_james@emolecules.com> wrote: >> We had to temporarily assign two IP addresses to our servers. After doing >> so and rebooting, Londiste will start, but it just sits there doing nothing. >> The logfile has zero bytes, and it doesn't seem to connect to either the >> master or the slave database. >> >> We reconfigured Postgres to listen on both addresses, but the /etc/hosts >> tables still point to the original addresses (that is, the second IP address >> shouldn't matter). But I can connect to Postgres on either IP address on >> all servers. >> >> All other Postgres applications work. I can use psql, and our Perl DBI and >> PHP applications all work with no problems. >> >> When I invoke "londiste.py --verbose ...", the log file says: >> >> 2011-08018 16:35:47,250 22074 DEBUG Attaching >> >> And that's all. Nothing more ever happens. >> >> Help? Thanks! > Does the exact connect string you use in londiste config work > with psql? Like so: > > $ psql -d 'connstr' Yes. psql -d 'dbname=archive host=iridium user=postgres' connects with no problem. Thanks, Craig
On Fri, Aug 19, 2011 at 7:17 PM, Craig James <craig_james@emolecules.com> wrote: > On 8/19/11 1:40 AM, Marko Kreen wrote: >> On Fri, Aug 19, 2011 at 2:44 AM, Craig James<craig_james@emolecules.com> >> wrote: >>> >>> We had to temporarily assign two IP addresses to our servers. After >>> doing >>> so and rebooting, Londiste will start, but it just sits there doing >>> nothing. >>> The logfile has zero bytes, and it doesn't seem to connect to either the >>> master or the slave database. >>> >>> We reconfigured Postgres to listen on both addresses, but the /etc/hosts >>> tables still point to the original addresses (that is, the second IP >>> address >>> shouldn't matter). But I can connect to Postgres on either IP address on >>> all servers. >>> >>> All other Postgres applications work. I can use psql, and our Perl DBI >>> and >>> PHP applications all work with no problems. >>> >>> When I invoke "londiste.py --verbose ...", the log file says: >>> >>> 2011-08018 16:35:47,250 22074 DEBUG Attaching >>> >>> And that's all. Nothing more ever happens. >>> >>> Help? Thanks! >> >> Does the exact connect string you use in londiste config work >> with psql? Like so: >> >> $ psql -d 'connstr' > > Yes. > > psql -d 'dbname=archive host=iridium user=postgres' > > connects with no problem. Hm. Londiste does not do anything fancy with connections. Perhaps you have some other problem. Does 'londiste conf.ini provider tables' work? Does 'londiste conf.ini subscriber tables' work? Do you have pgqadm running on provider db? -- marko
On 8/19/11 1:40 AM, Marko Kreen wrote: > On Fri, Aug 19, 2011 at 2:44 AM, Craig James<craig_james@emolecules.com> wrote: >> We had to temporarily assign two IP addresses to our servers. After doing >> so and rebooting, Londiste will start, but it just sits there doing nothing. >> The logfile has zero bytes, and it doesn't seem to connect to either the >> master or the slave database. >> >> We reconfigured Postgres to listen on both addresses, but the /etc/hosts >> tables still point to the original addresses (that is, the second IP address >> shouldn't matter). But I can connect to Postgres on either IP address on >> all servers. >> >> All other Postgres applications work. I can use psql, and our Perl DBI and >> PHP applications all work with no problems. >> >> When I invoke "londiste.py --verbose ...", the log file says: >> >> 2011-08018 16:35:47,250 22074 DEBUG Attaching >> >> And that's all. Nothing more ever happens. >> >> Help? Thanks! > Does the exact connect string you use in londiste config work > with psql? Like so: > > $ psql -d 'connstr' As I mentioned earlier, yes it does work. I also discovered by looking at all the postgres processes that it's making the first connection (to the master), but itdoesn't seem to even try to make the second connection. Could there be something else it's waiting for? The dual-network issue may be completely irrelevant. I know that whilethe IT guy was reconfiguring the network, he had to do a forced-reboot at least once without shutting down Postgres. Is it possible that the Londiste tables are in some invalid state, and the daemon is waiting for something that'snever going to happen? Thanks, Craig
On Fri, Aug 19, 2011 at 8:55 PM, Craig James <craig_james@emolecules.com> wrote: > On 8/19/11 1:40 AM, Marko Kreen wrote: >> >> On Fri, Aug 19, 2011 at 2:44 AM, Craig James<craig_james@emolecules.com> >> wrote: >>> >>> We had to temporarily assign two IP addresses to our servers. After >>> doing >>> so and rebooting, Londiste will start, but it just sits there doing >>> nothing. >>> The logfile has zero bytes, and it doesn't seem to connect to either the >>> master or the slave database. >>> >>> We reconfigured Postgres to listen on both addresses, but the /etc/hosts >>> tables still point to the original addresses (that is, the second IP >>> address >>> shouldn't matter). But I can connect to Postgres on either IP address on >>> all servers. >>> >>> All other Postgres applications work. I can use psql, and our Perl DBI >>> and >>> PHP applications all work with no problems. >>> >>> When I invoke "londiste.py --verbose ...", the log file says: >>> >>> 2011-08018 16:35:47,250 22074 DEBUG Attaching >>> >>> And that's all. Nothing more ever happens. >>> >>> Help? Thanks! >> >> Does the exact connect string you use in londiste config work >> with psql? Like so: >> >> $ psql -d 'connstr' > > As I mentioned earlier, yes it does work. > > I also discovered by looking at all the postgres processes that it's making > the first connection (to the master), but it doesn't seem to even try to > make the second connection. > > Could there be something else it's waiting for? The dual-network issue may > be completely irrelevant. I know that while the IT guy was reconfiguring > the network, he had to do a forced-reboot at least once without shutting > down Postgres. Is it possible that the Londiste tables are in some invalid > state, and the daemon is waiting for something that's never going to happen? Look at the logs, what queries does it do? -- marko