Re: [GENERAL] Unable to connect to Postgresql

On 04/07/2017 07:45 PM, Joe Conway wrote: On 04/07/2017 05:35 PM, Adrian Klaver wrote: On 04/07/2017 05:03 PM, John Iliffe wrote: Running on Fedora 25 with SELinux in PERMISSIVE mode. The audit log shows no hits on Postgresql. My going in position was/still is, that this is a SELinux

Re: [GENERAL] A change in the Debian install

Hello Adrian, On Thu, 2017-04-06 at 21:24 -0700, Adrian Klaver wrote: > On 04/06/2017 08:01 PM, rob stone wrote: > > > > > > > That is the default location and is generally the case in a source  > install. Package maintainers can and do often put them elsewhere. > AFAIK  > the Debian/Ubuntu

Re: [GENERAL] SELECT and RowExclusiveLock

Tim Nelson writes: > New to Postgres and I have never seen this condition. We are getting test > applications hanging on SELECT statements with a RowExclusiveLock. How can > a SELECT cause a RowExclusiveLock? > relname | pid | mode | granted >

Re: [GENERAL] Unable to connect to Postgresql

On 04/07/2017 05:35 PM, Adrian Klaver wrote: > On 04/07/2017 05:03 PM, John Iliffe wrote: Running on Fedora 25 with SELinux in PERMISSIVE mode. The audit log shows no hits on Postgresql. >> My going in position was/still is, that this is a SELinux security >> problem >> but I am

Re: [GENERAL] Unable to connect to Postgresql

On Friday 07 April 2017 20:39:55 Adrian Klaver wrote: > On 04/07/2017 05:10 PM, John Iliffe wrote: > Actually Ccing list this time > > > On Friday 07 April 2017 19:51:57 you wrote: > >> On 04/07/2017 04:57 PM, John Iliffe wrote: > >>> Hi Adrian: > > Well, it ain't that simple! I am trying to

Re: [GENERAL] Unable to connect to Postgresql

On Friday 07 April 2017 20:35:40 Adrian Klaver wrote: > On 04/07/2017 05:03 PM, John Iliffe wrote: > > Please reply to list also Yes, sorry about that. > Ccing list. > > > On Friday 07 April 2017 18:58:15 you wrote: > >> On 04/07/2017 02:38 PM, John Iliffe wrote: > >>> When I attempt to run any

Re: [GENERAL] Unable to connect to Postgresql

On 04/07/2017 05:10 PM, John Iliffe wrote: Actually Ccing list this time On Friday 07 April 2017 19:51:57 you wrote: On 04/07/2017 04:57 PM, John Iliffe wrote: Hi Adrian: Well, it ain't that simple! I am trying to take advantage of having a new server that doesn't have to be in

Re: [GENERAL] Unable to connect to Postgresql

On 04/07/2017 05:03 PM, John Iliffe wrote: Please reply to list also Ccing list. On Friday 07 April 2017 18:58:15 you wrote: On 04/07/2017 02:38 PM, John Iliffe wrote: When I attempt to run any web application php cannot open a database because of failure to connect. (Please disregard the

Re: [GENERAL] Unable to connect to Postgresql

On 04/07/2017 04:57 PM, John Iliffe wrote: Hi Adrian: Not the same problem. Last time I couldn't get postgresql running at all. This time it is running and I can't connect to it. I did check for something else holding the socket, but as far as I can see nothing else has it. So when was the

Re: [GENERAL] Unable to connect to Postgresql

Hi Adrian: Not the same problem. Last time I couldn't get postgresql running at all. This time it is running and I can't connect to it. I did check for something else holding the socket, but as far as I can see nothing else has it. Regards, John === On

Re: [GENERAL] Unable to connect to Postgresql

On 04/07/2017 02:38 PM, John Iliffe wrote: When I attempt to run any web application php cannot open a database because of failure to connect. (Please disregard the programme name, it is running in mod_php, not as an fcgi module). The (php) message is: -- [Fri Apr 07

Re: [GENERAL] Unable to connect to Postgresql

On 04/07/2017 02:38 PM, John Iliffe wrote: When I attempt to run any web application php cannot open a database because of failure to connect. (Please disregard the programme name, it is running in mod_php, not as an fcgi module). The (php) message is: -- [Fri Apr 07

[GENERAL] Unable to connect to Postgresql

When I attempt to run any web application php cannot open a database because of failure to connect. (Please disregard the programme name, it is running in mod_php, not as an fcgi module). The (php) message is: -- [Fri Apr 07 17:03:28.597101 2017] [php7:warn] [pid

Re: [GENERAL] SELECT and RowExclusiveLock

On Fri, Apr 7, 2017 at 1:25 PM, Tim Nelson wrote: > New to Postgres and I have never seen this condition. We are getting test > applications hanging on SELECT statements with a RowExclusiveLock. How can > a SELECT cause a RowExclusiveLock? > Two common ways: SELECT ... FOR

Re: [GENERAL] SELECT and RowExclusiveLock

On 04/07/2017 01:25 PM, Tim Nelson wrote: New to Postgres and I have never seen this condition. We are getting test applications hanging on SELECT statements with a RowExclusiveLock. How can a SELECT cause a RowExclusiveLock? relname | pid | mode | granted

[GENERAL] SELECT and RowExclusiveLock

New to Postgres and I have never seen this condition. We are getting test applications hanging on SELECT statements with a RowExclusiveLock. How can a SELECT cause a RowExclusiveLock? relname | pid | mode | granted

Re: [GENERAL] pg_dump: creates dumps that cannot be restored

Hi *, I’ve tried both setting the constraints temporarily to invalid (works) and converting (painstakingly slow, as this is new for me) to triggers (also works). Both can be dumped and restored. I’ve also found out that I probably can ship the schema update that converts the CHECK constraint to

Re: [GENERAL] [ADMIN] calculating table and index size

Le 7 avr. 2017 4:58 PM, "Alban Hertroys" a écrit : On 7 April 2017 at 09:11, Günce Kaya wrote: > Hi again, > > Sorry for delay. > > Guillaume, I read your answer for first question but It's not clear to me. > The table has a column and index also use

Re: [GENERAL] [ADMIN] calculating table and index size

On 7 April 2017 at 09:11, Günce Kaya wrote: > Hi again, > > Sorry for delay. > > Guillaume, I read your answer for first question but It's not clear to me. > The table has a column and index also use that column. so in that example, I > think table size and index size

Re: [GENERAL] A change in the Debian install

On 04/05/2017 09:05 PM, Tom Lane wrote: (But ... these statements are based on an assumption of out-of-the- box Postgres behavior. I would not exactly put it past the Debian packagers to have decided to change this for reasons of their own, and their track record of telling us about such

Re: [GENERAL] keeping WAL after dropping replication slots

On 04/06/2017 11:18 PM, Tom DalPozzo wrote: Hi, 2017-04-06 21:51 GMT+02:00 Adrian Klaver >: On 04/04/2017 11:52 PM, Tom DalPozzo wrote: Hi, 2017-04-05 1:55 GMT+02:00 Adrian Klaver

Re: [GENERAL] A change in the Debian install

Re: Magnus Hagander 2017-04-06 > On Thu, Apr 6, 2017 at 3:46 PM, Stephen Frost wrote: > > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > (But ... these statements are based on an assumption of out-of-the- >

Re: [GENERAL] [ADMIN] calculating table and index size

Hi again, Sorry for delay. Guillaume, I read your answer for first question but It's not clear to me. The table has a column and index also use that column. so in that example, I think table size and index size should be equal. Why these are not equal? Your answer for second question is pretty

Re: [GENERAL] keeping WAL after dropping replication slots

Postgres version? 9.6.1 Have you considered upgrading to 9.6.2? There were some fixes, including WAL related: https://www.postgresql.org/docs/9.6/static/release-9-6-2.html Not exactly regarding what you see, though... Bye, Chris. -- Sent via pgsql-general mailing

Re: [GENERAL] keeping WAL after dropping replication slots

Hi, 2017-04-06 21:51 GMT+02:00 Adrian Klaver : > On 04/04/2017 11:52 PM, Tom DalPozzo wrote: > >> Hi, >> >> 2017-04-05 1:55 GMT+02:00 Adrian Klaver > >: >> >> On 04/04/2017 07:45 AM, Tom DalPozzo wrote: