Re: [BUGS] password auth woes on sparc64/FreeBSD
I tested on Solaris AMD64 and Sparc v240 (64bit) and it works for me. Do you use 32bit or 64bit version of postgreSQL and what you have in .pgpass? Zdenek Volodymyr Kostyrko wrote: It seems to me that auth on the local interface(?) is broken somehow on sparc64. [data/pg_hba.conf] local postgres,template1 all trust local postgres,template1 all md5 host postgres,template1 all 0.0.0.0/0 md5 host postgres,template1 all ::/0 md5 [--] Well, what I really want to do is to remove the trust line from config. But that way i need a .pgpass file so the server can start/control itself without asking me for password. And if i want .pgpass file i need some auth. [session transcript/same machine] > psql -U pgsql postgres Welcome to psql 8.2.4, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# alter role pgsql password 'somepass'; ALTER ROLE postgres=# \q > psql -h localhost -U pgsql postgres Password for user pgsql: psql: FATAL: password authentication failed for user "pgsql" [--] It fails for any user and any password. [session transcript/other machine] > psql -h blade -U pgsql postgres Password for user pgsql: Welcome to psql 8.2.4, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# [--] But I can log from another machine flawlessly... > uname -a FreeBSD blade.lan 6.2-STABLE FreeBSD 6.2-STABLE #13: Tue Jun 5 17:06:57 EEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BLADE sparc64 PS: Can assist in debugging if someone would point me what and how. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] password auth woes on sparc64/FreeBSD
Zdenek Kotala wrote: I tested on Solaris AMD64 and Sparc v240 (64bit) and it works for me. Do you use 32bit or 64bit version of postgreSQL and what you have in .pgpass? I use sparc64 and my .pgpass file was like: localhost:5432:*:pgsql:password Actually i have already found the cause. Authorization fails when postgresql-client was compiled with -O3 but it works otherwise. Maybe it is just another gcc optimization issue. -- Sphinx of black quartz judge my vow! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] password auth woes on sparc64/FreeBSD
Volodymyr Kostyrko wrote: Zdenek Kotala wrote: I tested on Solaris AMD64 and Sparc v240 (64bit) and it works for me. Do you use 32bit or 64bit version of postgreSQL and what you have in .pgpass? I use sparc64 and my .pgpass file was like: localhost:5432:*:pgsql:password Actually i have already found the cause. Authorization fails when postgresql-client was compiled with -O3 but it works otherwise. Maybe it is just another gcc optimization issue. OK. Good to know. GCC also does not generate much optimal SPARC code. Unfortunately, If you use FreeBSD on SPARC, I think there is no another possibility (another C compiler). Zdenek ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] Autovacuum vacuums not setting start time in pg_stat_activity
This is on a 8.2.3 database; vacuums started by autovacuum don't get their query_start time set. select * from pg_stat_activity where current_query like 'VACUUM%'; -[ RECORD 1 ]-+- datid | 16384 datname | emma2 procpid | 8674 usesysid | 10 usename | postgres current_query | VACUUM public.userdata_2409_messages_history waiting | f query_start | backend_start | 2007-06-12 15:29:53.376641-05 client_addr | client_port | -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Autovacuum vacuums not setting start time in pg_stat_activity
"Jim Nasby" <[EMAIL PROTECTED]> writes: > This is on a 8.2.3 database; vacuums started by autovacuum don't get > their query_start time set. Hmm. Query_start is actually defined as "time of last client command receipt", so it's null just like client_addr/port are. Not sure if there's anything we should put there that's more meaningful than the backend start time. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] Autovacuum vacuums not setting start time in pg_stat_activity
Tom Lane wrote: > "Jim Nasby" <[EMAIL PROTECTED]> writes: > > This is on a 8.2.3 database; vacuums started by autovacuum don't get > > their query_start time set. > > Hmm. Query_start is actually defined as "time of last client command > receipt", so it's null just like client_addr/port are. Not sure if > there's anything we should put there that's more meaningful than the > backend start time. Let's put the current command (vacuum/analyze) start time in there. Backend start time, I assume, is the time at which the current autovac iteration was started. Should this be backpatched if changed in 8.3? -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] Autovacuum vacuums not setting start time in pg_stat_activity
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Should this be backpatched if changed in 8.3? I'd vote no; it's pretty hard to argue that it's a bug fix as opposed to a cosmetic improvement. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
