Re: [ADMIN] phpPgAdmin configuration
Hello: Is it a passwordless account? I ran in such an error using a passwordless account. Since the error supposes a successful connection to the server & unsuccessful login attempt, I guess apache is running ok and the vhost is also correctly configured, but maybe you could have a look at its configuration? I run Fedora & have encountered similar problems on every upgrade (shame on me, I forget about it until the next upgrade...) Barbara > I installed phpPgAdmin on my red hat box in the /var/www/html directory. > I edited the pg_hba.conf file as many tutorials stated with the lines. > local allall > trust > host allall127.0.0.1/32 trust > > When I try to login to phpPgAdmin with a user account that I created, > using the CREATE USER command, I get the login failed message. > > What else do I need to configure to allow access with phpPgAdmin? > > Thanks > > Marc > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] Converting from 7.4.19 To 8.3.1 & want to use autovacuum
Hello, We are new about autovacuum launcher on 8.3.1 and we are not sure what the parameters should be set to. Is setting them to default ok until we can monitor if it's vacumming too much? Below are the parameters that we think are the only params we need to do a basic vacuum and analyze to our entire database. autovacuum=true track_counts=ture log_autovacuum_min_duration=1000ms autovacuum_max_workers=3(default) autovacuum_naptime=60 autovacuum_vacuum_threshold=50(default) Are the above settings all we need to start auto vacuuming? -- Regards, Barbara Stephenson EDI Specialist/Programmer Turbo, division of Ozburn-Hessey Logistics 2251 Jesse Jewell Pkwy NE Gainesville, GA 30507 tel: (678)989-3020 fax: (404)935-6171 [EMAIL PROTECTED] www.ohlogistics.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Converting from 7.4.19 To 8.3.1 & want to use autovacuum
Oh I have to look at the other parameters. Once the database is up and it's not vacuuming like we want how do we make changes to the conf file while the database is running? Some signal? Guillaume Lelarge wrote: > Hi, > > Barbara Stephenson a écrit : > > We are new about autovacuum launcher on 8.3.1 and we are not sure what > > the parameters should be set to. Is setting them to default ok until we > > can monitor if it's vacumming too much? > > You can do that. But the default are, as always with PostgreSQL, really > conservative. So you'll probably need to change them because it will not > vacuum enough. > > > Below are the parameters that we think are the only params we need to do > > a basic vacuum and analyze to our entire database. > > > > autovacuum=true > > track_counts=ture > > log_autovacuum_min_duration=1000ms > > autovacuum_max_workers=3(default) > > autovacuum_naptime=60 > > autovacuum_vacuum_threshold=50(default) > > > > Are the above settings all we need to start auto vacuuming? > > ISTM you forgot autovacuum_vacuum_scale_factor and the analyze parameters. > > Regards. > > > -- > Guillaume. > http://www.postgresqlfr.org > http://dalibo.com -- Regards, Barbara Stephenson EDI Specialist/Programmer Turbo, division of Ozburn-Hessey Logistics 2251 Jesse Jewell Pkwy NE Gainesville, GA 30507 tel: (678)989-3020 fax: (404)935-6171 [EMAIL PROTECTED] www.ohlogistics.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] open source ERD for postgresql database
I would like to use an ERD tool for postgres and it be open source. Any suggestions? -- Regards, Barbara Stephenson EDI Specialist/Programmer Turbo, division of Ozburn-Hessey Logistics 2251 Jesse Jewell Pkwy NE Gainesville, GA 30507 tel: (678)989-3020 fax: (404)935-6171 [EMAIL PROTECTED] www.ohlogistics.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] Recommend dba maintenance tasks on a regular bases
Hello, We are currently using Postgresql 8.3.3 on Red Hat 4 and our largest database is around 8454 MB. I have recommend the below to my group but not sure if reindexing should be involved since autovacuum is on? How can I be sure auto vacumming is working fine? We haven't had any problems plus I do a query and it does list all the tables and shows the last update of auto vacuum and auto analyze. Is that it? 1- pg_dump - binary dump every midday and nightly 2 - auto vacuum autovacuum = on log_autovacuum_min_duration = 0 autovacuum_max_workers = 3 autovacuum_naptime = 1min autovacuum_vacuum_threshold = 50 autovacuum_vacuum_scale_factor = 0.2 autovacuum_analyze_scale_factor = 0.1 3- rotate data logs -- Regards, Barbara Stephenson EDI Specialist/Programmer Turbo, division of Ozburn-Hessey Logistics 2251 Jesse Jewell Pkwy NE Gainesville, GA 30507 tel: (678)989-3020 fax: (404)935-6171 [EMAIL PROTECTED] www.ohlogistics.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] open source ERD for postgresql database
Thank you all for your input. Yes I would like to get an ERD for an existing system plus to create a new system. All the ones recommended are any of them for Linux. Our database resides on Redhat 4. I prefer free/open source so I can at least take a look to see if it's user friendly. However, I know some do have a 30 day trial. Barbara Anibal David Acosta wrote: > MICRO-OLAP Database designer for postgres is a great tool. > > > > -Mensaje original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de Carol Walter > Enviado el: lunes, 15 de septiembre de 2008 02:58 p.m. > Para: Thomas Jacob > CC: Barbara Stephenson; pgsql-admin@postgresql.org > Asunto: Re: [ADMIN] open source ERD for postgresql database > > This sort of depends on what you want to do with the ERD. If I want > to document an existing system, I use Aqua Data Studio. It's not > free, but it will take an existing system and draw the ERD for you > based on the relationships it finds in the database. There are > things that I don't like about it. It puts the tables into the ERD > in alpha order. This leads to some spaghetti ERD's. You can move > the tables around and then save them. The problem is that once they > are saved, it's an image and you can't move them anymore. If you > recreate the ERD you have to begin again to move the tables around. > Another tool that some people like, but that I haven't used is called > SQL-EZ. It's cost is trivial. > > Carol > > On Sep 12, 2008, at 10:24 AM, Thomas Jacob wrote: > > I've been using GNU ferret for a while, it's OK > > for simple tasks, and can produce table graphs and > > even output rudimentary PostgreSQL DDL in Version 0.6, > > but it doesn't support PostgreSQL's full range of types yet > > and the handling is somewhat awkward. > > > > Version 0.7 looks much more promising, at least from > > the screen shots, but that hasn't been release yet: > > > > http://www.gnuferret.org/ > > > > On Fri, 2008-09-12 at 09:59 -0400, Barbara Stephenson wrote: > >> I would like to use an ERD tool for postgres and it be open > >> source. Any > >> suggestions? > >> -- > >> Regards, > >> > >> Barbara Stephenson > >> EDI Specialist/Programmer > >> Turbo, division of Ozburn-Hessey Logistics > >> 2251 Jesse Jewell Pkwy NE > >> Gainesville, GA 30507 > >> tel: (678)989-3020 fax: (404)935-6171 > >> [EMAIL PROTECTED] > >> www.ohlogistics.com > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin -- Regards, Barbara Stephenson EDI Specialist/Programmer Turbo, division of Ozburn-Hessey Logistics 2251 Jesse Jewell Pkwy NE Gainesville, GA 30507 tel: (678)989-3020 fax: (404)935-6171 [EMAIL PROTECTED] www.ohlogistics.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Recommend dba maintenance tasks on a regular bases
HI Jeff, Thank you for the link to explain FSM however I understand the concept where it would be faster to know where to store data based on an insert or an update but the results of the last few lines of the verbose I still don't get it. Our max_fsm_relations = 1000 and max_fsm_pages=153600 We have auto vacuum running and below is the last few lines from a vacuum verbose statement. Can you explain and do I need to adjust our settings? INFO: free space map contains 51228 pages in 501 relations DETAIL: A total of 57328 page slots are in use (including overhead). 57328 page slots are required to track all free space. Current limits are: 153600 page slots, 1000 relations, using 965 kB. Jeff Frost wrote: > On Fri, 12 Sep 2008, Barbara Stephenson wrote: > > 1- pg_dump - binary dump every midday and nightly > > 2 - auto vacuum > > 3- rotate data logs > > You should also consider running a script which does a VACUUM VERBOSE > weekly or twice monthly and emails you the last 8 lines of output. This > will allow you to keep your FSM settings up to date. > > Jim Nasby's article here: http://decibel.org/~decibel/pervasive/fsm.html > has some good info about the Free Space Map if you're not familiar with it. > > In addition, it's probably worth setting log_min_duration_statement to > something like 500 or 1000 (500ms or 1s) so that you log slow queries. > Note that 500ms is just an example, set it to a value you consider slow so > that it will log your slow queries. Then, after you've gathered some > data, run it through pgfouine. http://pgfouine.projects.postgresql.org/ -- Regards, Barbara Stephenson EDI Specialist/Programmer Turbo, division of OHL 2251 Jesse Jewell Pkwy Gainesville, GA 30507 tel: (678)989-3020 fax: (404)935-6171 [EMAIL PROTECTED] www.ohl.com
Re: [ADMIN] open source ERD for postgresql database
Sorry just now had some time to look at this but unfortunately this is not for PG on linux. :( Anibal David Acosta wrote: > MICRO-OLAP Database designer for postgres is a great tool. > > > > -Mensaje original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de Carol Walter > Enviado el: lunes, 15 de septiembre de 2008 02:58 p.m. > Para: Thomas Jacob > CC: Barbara Stephenson; pgsql-admin@postgresql.org > Asunto: Re: [ADMIN] open source ERD for postgresql database > > This sort of depends on what you want to do with the ERD. If I want > to document an existing system, I use Aqua Data Studio. It's not > free, but it will take an existing system and draw the ERD for you > based on the relationships it finds in the database. There are > things that I don't like about it. It puts the tables into the ERD > in alpha order. This leads to some spaghetti ERD's. You can move > the tables around and then save them. The problem is that once they > are saved, it's an image and you can't move them anymore. If you > recreate the ERD you have to begin again to move the tables around. > Another tool that some people like, but that I haven't used is called > SQL-EZ. It's cost is trivial. > > Carol > > On Sep 12, 2008, at 10:24 AM, Thomas Jacob wrote: > > I've been using GNU ferret for a while, it's OK > > for simple tasks, and can produce table graphs and > > even output rudimentary PostgreSQL DDL in Version 0.6, > > but it doesn't support PostgreSQL's full range of types yet > > and the handling is somewhat awkward. > > > > Version 0.7 looks much more promising, at least from > > the screen shots, but that hasn't been release yet: > > > > http://www.gnuferret.org/ > > > > On Fri, 2008-09-12 at 09:59 -0400, Barbara Stephenson wrote: > >> I would like to use an ERD tool for postgres and it be open > >> source. Any > >> suggestions? > >> -- > >> Regards, > >> > >> Barbara Stephenson > >> EDI Specialist/Programmer > >> Turbo, division of Ozburn-Hessey Logistics > >> 2251 Jesse Jewell Pkwy NE > >> Gainesville, GA 30507 > >> tel: (678)989-3020 fax: (404)935-6171 > >> [EMAIL PROTECTED] > >> www.ohlogistics.com > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin -- Regards, Barbara Stephenson EDI Specialist/Programmer Turbo, division of OHL 2251 Jesse Jewell Pkwy Gainesville, GA 30507 tel: (678)989-3020 fax: (404)935-6171 [EMAIL PROTECTED] www.ohl.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] tuning our database by increasing shared buffer
Hello, We will be consolidating from 4 databases to 2 and want to make sure that these parameters are the only ones that need changing. Please advise. Current Future = = Max_connection = 50 125 Shared_buffers = 16MB 48MB My concern is that max_locks_per_transaction and max_prepared_transaction are still set as default?? Shouldn't we increase the max_locks_per_transaction from 64 to 100 or 128 since we have more than doubled the # of connections? max_prepared_transaction is set at default of 5 which is says if we use it to set it to max_connection. Or leaving those 2 max parameters as default would be ok? -- Regards, Barbara Stephenson EDI Specialist/Programmer Turbo, division of OHL 2251 Jesse Jewell Pkwy Gainesville, GA 30507 tel: (678)989-3020 fax: (404)935-6171 barb...@turbocorp.com www.ohl.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] tuning our database by increasing shared buffer
Thank ypu! Tom Lane wrote: Barbara Stephenson writes: We will be consolidating from 4 databases to 2 and want to make sure that these parameters are the only ones that need changing. Please advise. Current Future = = Max_connection = 50 125 Shared_buffers = 16MB 48MB You will need to make sure that the FSM size parameters are correct for the combined databases, too. Shouldn't we increase the max_locks_per_transaction from 64 to 100 or 128 since we have more than doubled the # of connections? No, because the lock table size automatically scales with max_connections. (Probably max_locks_per_transaction should have been called max_locks_per_connection ...) max_prepared_transaction is set at default of 5 which is says if we use it to set it to max_connection. Are you using prepared transactions at all? If not, I'd actually recommend setting that to zero to make sure nobody creates a prepared transaction accidentally. You do *not* want anyone doing PREPARE TRANSACTION unless there's an XA manager or something in place to make sure the prepared xact gets committed or rolled back reasonably soon. regards, tom lane -- Regards, Barbara Stephenson /EDI Specialist/Programmer/ *Turbo, division of OHL* 2251 Jesse Jewell Pkwy *Gainesville, GA 30507* tel: (678)989-3020 fax: (404)935-6171 barb...@turbocorp.com www.ohl.com
