Re: psql connection issue
| От | Adrian Klaver |
|---|---|
| Тема | Re: psql connection issue |
| Дата | |
| Msg-id | 543539D6.20907@aklaver.com обсуждение исходный текст |
| Ответ на | Re: psql connection issue (Stephen Davies <sdavies@sdc.com.au>) |
| Ответы |
Re: psql connection issue
|
| Список | pgsql-general |
On 10/07/2014 09:10 PM, Stephen Davies wrote: > The permissions on the socket are 777 owner/group postgres. > > I installed the 9.3 onto the Centos 7 server using the repo at > postgresql.org. > > (http://yum.postgresql.org/9.3/redhat/rhel-$releasever-$basearch) > > There is no /var/run/postgresql and find cannot find another socket > anywhere else. Sounds similar to this: Long version: http://serverfault.com/questions/609947/database-connection-to-postgresql-refused-for-flask-app-under-mod-wsgi-when-start Short version: Disable SELinux > > Cheers and thanks, > Stephen > > On 08/10/14 14:32, Tom Lane wrote: >> Stephen Davies <sdavies@sdc.com.au> writes: >>> I am in the process of migrating a bunch of databases and associated CGI >>> scripts from 9.1.4 to 9.3 (and from 32-bit to 64-bit). >> >>> The database migration has been successful but I have an issue with psql >>> connections from CGI scripts. >> >>> I can connect to the 9.3 server locally with psql from the command >>> line, with >>> psql from other boxes on the LAN via TCP, via JDBC from programs and >>> servlets >>> but cannot connect locally via CGI. >> >>> If I run any of the CGI scripts from the command line they work but when >>> invoked by Apache, they fail with the usual question as to whether >>> anything is >>> listening on socket /tmp/.s.PGSQL.5432. >> >> Some Linux variants think it improves security to run daemons like apache >> in a context where what the daemon sees as /tmp has been mapped somewhere >> else. >> >> If you're running one of these platforms, the Postgres server and libpq >> distributed by the vendor will have been hacked to cope, typically by >> agreeing that the socket location is something like /var/run/postgresql/ >> rather than /tmp. I'm guessing your 9.3 installation was self-built >> and hasn't been configured that way. >> >> regards, tom lane >> > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: