Обсуждение: 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... :)