Thread: postgres authentication
Hi, I changed my pg_hba.conf file so that I am authenticating using md5 from passwdfile which is a file i created to hold my passwords. I didn't add postgres onto that file but when I type psql template1 under postgres, it prompts me for my password. i type it in and it gives me psql: FATAL 1: Password authentication failed for user "postgres" I only have one password for postgres which I used perfectly fine to log into linux. I also use the same password to switch between postgres and other non-root users in the bash shell. i tried adding postgres into the passwdfile file but to no avail. How do I correct this password bug for postgres so that I can do stuff as a superuser? HELP! Alex
acchung@mit.edu wrote: > Hi, > > I changed my pg_hba.conf file so that I am authenticating using > md5 from passwdfile which is a file i created to hold my passwords. > I didn't add postgres onto that file but when I type psql template1 > under postgres, it prompts me for my password. i type it in > and it gives me > > psql: FATAL 1: Password authentication failed for user "postgres" > > I only have one password for postgres which I used perfectly fine > to log into linux. I also use the same password to switch between > postgres and other non-root users in the bash shell. i tried adding postgres > into the passwdfile file but to no avail. How do I correct this > password bug for postgres so that I can do stuff as a superuser? > HELP! That file is used for secondary passwords. It is going away in 7.3 so I suggest using ALTER USER PASSWORD to set the password for the user in the pg_shadow table. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Hi group! I've seen the page http://www.postgresql.org/idocs/index.php?routine-vacuuming.html where is explained the benefit offered by the vaccum. I've made a test with my software: before vaccuming: 478 "operations" after vaccuming: 1378 "operations" Good, but the documentation reports: - Beginning in PostgreSQL 7.2, the standard form of VACUUM can run in parallel with normal database operations. If my DB is a 7.1.3 what happens? - Prior to PostgreSQL 7.2, the only defense against XID wraparound was to re-initdb at least every 4 billion transactions. And in the 7.1.3 Is it safe to run the vaccum on a production DB? I've also planned to setup a ramdisk to improve the performances.. is it a good choice? TIA, Auri
On Thu, 11 Jul 2002, Auri Mason wrote: > Good, but the documentation reports: > - Beginning in PostgreSQL 7.2, the standard form of VACUUM can run in > parallel with normal database operations. If my DB is a 7.1.3 what > happens? IIRC, it grabs an exclusive lock on the table it's working on, so other transactions block for the vacuum to finish. > - Prior to PostgreSQL 7.2, the only defense against XID wraparound was > to re-initdb at least every 4 billion transactions. And in the 7.1.3 > Is it safe to run the vaccum on a production DB? As long as you can live with the delay in queries, it should be barring any bugs I can't think of. > I've also planned to setup a ramdisk to improve the performances.. is > it a good choice? Unless your dataset is really small, you're probably better off with increasing shared buffers and letting the OS disk buffers take care of it. BTW: You may want to consider upgrading in general... :)