Re: [GENERAL] Unable to connect to Postgresql

[Adrian Klaver]

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 security
problem
but I am finding SELinux to be the most opaque and badly documented
software
that I have ever had to deal with, which is why it is running in
permissive
mode at the moment.


Well what I know about SELinux would fit in the navel of a flea(tip of
the hat to David Niven), so I can not be of much help there. The reason
I am returned this thread to the list, there are folks that do
understand it.


If SELinux is running in permissive I don't see how it could be at fault
for your issue. Did you verify that (getenforce)?


--
[Fri Apr 07 17:03:28.597101 2017] [php7:warn] [pid 1797:tid
140599445419776] [client 192.168.1.10:45127] PHP Warning:
pg_connect(): Unable to connect to PostgreSQL server: could not
connect to server: No such file or directory\n\tIs the server running
locally and
accepting\n\tconnections on Unix domain socket
/tmp/.s.PGSQL.5432? in /httpd/iliffe/testfcgi.php on line
121 


This might be a silly question, but is PHP running on the same server as
Postgres?


To add to this, previously you mentioned:

"Also, using the on board firewall (firewalld) to provide a secondary 
domain where the actual business processes run. "


What exactly does that mean?



HTH,

Joe




--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] A change in the Debian install

[rob stone]

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 way using postgresql-common is to put them in 
> /etc/postgresql/version/cluster_name/. So on one of my Ubuntu 16.04 
> installs with Postgres 9.6.2:
> 
> aklaver@arkansas:~$ l /etc/postgresql/9.6/main/
> total 56
> drwxr-xr-x 2 postgres postgres  4096 Feb 11 16:23 ./
> drwxr-xr-x 3 postgres postgres  4096 Feb 11 07:15 ../
> -rw-r--r-- 1 postgres postgres   315 Feb 11 07:15 environment
> -rw-r--r-- 1 postgres postgres   143 Feb 11 07:15 pg_ctl.conf
> -rw-r- 1 postgres postgres  4642 Feb 11 16:23 pg_hba.conf
> -rw-r- 1 postgres postgres  1636 Feb 11 07:15 pg_ident.conf
> -rw-r--r-- 1 postgres postgres 22438 Feb 11 16:11 postgresql.conf
> -rw-r--r-- 1 postgres postgres   317 Feb 11 07:15 start.conf
> 
> 
> and PGDATA:
> 
> aklaver@arkansas:~$ sudo ls -al /var/lib/postgresql/9.6/main/
> total 92
> drwx-- 19 postgres postgres 4096 Apr  6 15:54 .
> drwxr-xr-x  3 postgres postgres 4096 Feb 11 07:15 ..
> drwx--  6 postgres postgres 4096 Feb 11 16:06 base
> drwx--  2 postgres postgres 4096 Mar 22 12:22 global
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_clog
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_commit_ts
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_dynshmem
> drwx--  4 postgres postgres 4096 Feb 11 07:15 pg_logical
> drwx--  4 postgres postgres 4096 Feb 11 07:15 pg_multixact 
> drwx--  2 postgres postgres 4096 Mar 22 12:21 pg_notify 
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_replslot 
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_serial 
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_snapshots 
> drwx--  2 postgres postgres 4096 Mar 22 12:21 pg_stat 
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_stat_tmp 
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_subtrans 
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_tblspc 
> drwx--  2 postgres postgres 4096 Feb 11 07:15 pg_twophase 
> -rw---  1 postgres postgres4 Feb 11 07:15 PG_VERSION 
> drwx--  3 postgres postgres 4096 Feb 11 07:15 pg_xlog 
> -rw---  1 postgres postgres   88 Feb 11 07:15
> postgresql.auto.conf 
> -rw---  1 postgres postgres  133 Mar 22 12:21 postmaster.opts 
> -rw---  1 postgres postgres  100 Mar 22 12:21 postmaster.pid
> 

> This is why I am trying to figure out if you are using the Debian
> packaging:
> 
> A) What is your PGDATA?
> 
> B) How postgresql.conf got there?
> 
> The reason it is important is that the next update will probably
> land 
> you back in the same situation that started this thread, unless we 
> figure out what is going on.
> 
> Another question:
> 
> Have you ever installed Postgres on this machine using something
> other 
> then the Debian packages?
> 


Everything is done via a bog standard install from Debian repos.

The installation process creates a path containing these files:-

/etc/postgresql/9.5/main# ls -al
total 56
drwxr-xr-x 2 postgres postgres  4096 Jul  7  2016 .
drwxr-xr-x 3 postgres postgres  4096 Feb  3  2016 ..
-rw-r--r-- 1 postgres postgres   315 Feb  3  2016 environment
-rw-r--r-- 1 postgres postgres   143 Feb  3  2016 pg_ctl.conf
-rw-r- 1 postgres postgres  4641 Feb  3  2016 pg_hba.conf
-rw-r- 1 postgres postgres  1636 Feb  3  2016 pg_ident.conf
-rw-r--r-- 1 postgres postgres 21869 Feb  3  2016 postgresql.conf
-rw-r--r-- 1 postgres postgres   378 Feb  3  2016 start.conf

I can't show you the 9.6 ones as I removed them but they are on a
backup. However, the number of files is exactly as above.

The binaries are installed in /usr/lib/postgresl/VN/bin

You create a new cluster by running initdb:-

initdb -D /path/to/my/new/cluster

That path has to exist and be empty otherwise initdb throws an error
and exits. It then creates the sub-directories for pg_log, etc. and
drops in the three conf files as defaults.
You need to edit those conf files and set the parameters for your site.
E.g., autovacuum, work memory, etc.

Your PGDATA environment variable has to point to:-
/path/to/my/new/cluster
which means you need to set that up accordingly, depending on the
applications accessing that cluster.

You can create multiple clusters all running from the same set of
binaries.

I'm quite happy with the way in which the Debian packages are set up as
it means you can have multiple clusters and each can have its own
postgresql.conf file.
For example you might have a production database streaming to a slave,
a playpen database where users can try something out before running it
on production and a training database that you restore from a dump file
ate the beginning of each training session, and so forth.

My original post was about the access sequence to the 

Re: [GENERAL] SELECT and RowExclusiveLock

[Tom Lane]

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
> --+---+--+-
>  sales_transaction_detail |   392 | RowExclusiveLock | t
>  sales_transaction_detail | 19077 | RowExclusiveLock | t
>  sales_transaction_header | 32661 | RowExclusiveLock | t
>  sales_transaction_header |   392 | RowExclusiveLock | t
>  sales_transaction_header | 19077 | RowExclusiveLock | t

Hm, all those entries are showing granted = t, implying that they are
not blocked.  I think you are mis-querying pg_locks or mis-interpreting
the results.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Unable to connect to Postgresql

[Joe Conway]

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 finding SELinux to be the most opaque and badly documented
>> software
>> that I have ever had to deal with, which is why it is running in
>> permissive
>> mode at the moment.
> 
> Well what I know about SELinux would fit in the navel of a flea(tip of
> the hat to David Niven), so I can not be of much help there. The reason
> I am returned this thread to the list, there are folks that do
> understand it.

If SELinux is running in permissive I don't see how it could be at fault
for your issue. Did you verify that (getenforce)?

>> --
>> [Fri Apr 07 17:03:28.597101 2017] [php7:warn] [pid 1797:tid
>> 140599445419776] [client 192.168.1.10:45127] PHP Warning:
>> pg_connect(): Unable to connect to PostgreSQL server: could not
>> connect to server: No such file or directory\n\tIs the server running
>> locally and
>> accepting\n\tconnections on Unix domain socket
>> /tmp/.s.PGSQL.5432? in /httpd/iliffe/testfcgi.php on line
>> 121 

This might be a silly question, but is PHP running on the same server as
Postgres?

HTH,

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [GENERAL] Unable to connect to Postgresql

[John Iliffe]

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 take advantage of having a
> > new server that doesn't have to be in production until month end to
> > update everything to the latest and greatest.  Everything runs
> > properly on the existing server which is on Postgresql 9.2.1, using
> > mod_php to connect.
> > 
> > Changes that I have made are:  update Postgresql, PHP, and Apache,
> > change to fcgi from mod_php (which should not get involved here, but
> > I backed out that change and still doesn't work) and the addition of
> > SELinux for security (none on present server).
> 
> Aah, so a lot changed.
> 
> Do you have a way of trying to connect using PHP that does not involve
> going through Apache?

Yes, running in command line mode under root; the output from one of the 
cron jobs that hits the database seems to be as expected.  It uses a 
database that hasn't been loaded yet and the error message from the 
postgresql log says that.  (actually it says the role doesn't exist but 
that is the correct response)  The point is, it does connect because it 
tries to log in.

> 
> > Also, using the on board firewall (firewalld) to provide a secondary
> > domain where the actual business processes run.
> > 
> > So, I guess the answer is that the current arrangement has never run
> > correctly.
> > 
> >>> Regards,
> >>> 
> >>> John


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Unable to connect to Postgresql

[John Iliffe]

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 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 1797:tid
> >>> 140599445419776] [client 192.168.1.10:45127] PHP Warning:
> >>> pg_connect(): Unable to connect to PostgreSQL server: could not
> >>> connect to server: No such file or directory\n\tIs the server
> >>> running locally and
> >>> accepting\n\tconnections on Unix domain socket
> >>> /tmp/.s.PGSQL.5432? in /httpd/iliffe/testfcgi.php on
> >>> line 121 
> >>> 
> >>> The proper socket does exist:
> >>> 
> >>> -
> >>> ls -al /tmp | grep PGSQL
> >>> srwxrwxrwx.  1 postgres postgres0 Apr  7 16:53 .s.PGSQL.5432
> >>> -rw---.  1 postgres postgres   49 Apr  7 16:53
> >>> .s.PGSQL.5432.lock
> >>> 
> >>> ss -a | grep 5432
> >>> u_str  LISTEN 0  128/tmp/.s.PGSQL.5432 30480
> >>> 
> >>>  * 0 -
> >>> 
> >>> Running on Fedora 25 with SELinux in PERMISSIVE mode.  The audit log
> >>> shows no hits on Postgresql.
> >>> 
> >>> Postgresql version number is 9.6.2
> >>> 
> >>> As expected, the postgresql log shows nothing since the last start
> >>> up.
> >> 
> >> Meant to add to previous post:
> >> 
> >> What happens if you try to connect to the database using psql?
> > 
> > Works just as I would expect.
> > 
> > In fact, I was able to load the one of the databases from the pg_dump
> > backup using pg_restore without any problems either, and I checked the
> > results by running some in-stream transactions in psql.  Everything
> > went fine at that point, until I tried to start Apache and couldn't
> > connect.
> 
> To be precise PHP could not connect, correct?

Yes.  The "unable to connect" message is being issued by PHP.  But PHP 
seems to know what is required (Unix domain socket number and where to find 
it are both correct as far as I can see.
> 
> > My going in position was/still is, that this is a SELinux security
> > problem but I am finding SELinux to be the most opaque and badly
> > documented software that I have ever had to deal with, which is why
> > it is running in permissive mode at the moment.
> 
> Well what I know about SELinux would fit in the navel of a flea(tip of
> the hat to David Niven), so I can not be of much help there. The reason
> I am returned this thread to the list, there are folks that do
> understand it.
> 
> > Regards,
> > 
> > John
> > 
> >>> Thanks in advance.
> >>> 
> >>> John
> >>> =


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Unable to connect to Postgresql

[Adrian Klaver]

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 production until month end to update
everything to the latest and greatest.  Everything runs properly on the
existing server which is on Postgresql 9.2.1, using mod_php to connect.

Changes that I have made are:  update Postgresql, PHP, and Apache, change
to fcgi from mod_php (which should not get involved here, but I backed out
that change and still doesn't work) and the addition of SELinux for
security (none on present server).


Aah, so a lot changed.

Do you have a way of trying to connect using PHP that does not involve 
going through Apache?




Also, using the on board firewall (firewalld) to provide a secondary domain
where the actual business processes run.

So, I guess the answer is that the current arrangement has never run
correctly.


Regards,

John


--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Unable to connect to Postgresql

[Adrian Klaver]

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 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 1797:tid
140599445419776] [client 192.168.1.10:45127] PHP Warning:
pg_connect(): Unable to connect to PostgreSQL server: could not
connect to server: No such file or directory\n\tIs the server running
locally and
accepting\n\tconnections on Unix domain socket
/tmp/.s.PGSQL.5432? in /httpd/iliffe/testfcgi.php on line
121 

The proper socket does exist:

-
ls -al /tmp | grep PGSQL
srwxrwxrwx.  1 postgres postgres0 Apr  7 16:53 .s.PGSQL.5432
-rw---.  1 postgres postgres   49 Apr  7 16:53 .s.PGSQL.5432.lock

ss -a | grep 5432
u_str  LISTEN 0  128/tmp/.s.PGSQL.5432 30480
 * 0 -

Running on Fedora 25 with SELinux in PERMISSIVE mode.  The audit log
shows no hits on Postgresql.

Postgresql version number is 9.6.2

As expected, the postgresql log shows nothing since the last start up.


Meant to add to previous post:

What happens if you try to connect to the database using psql?


Works just as I would expect.

In fact, I was able to load the one of the databases from the pg_dump
backup using pg_restore without any problems either, and I checked the
results by running some in-stream transactions in psql.  Everything went
fine at that point, until I tried to start Apache and couldn't connect.


To be precise PHP could not connect, correct?



My going in position was/still is, that this is a SELinux security problem
but I am finding SELinux to be the most opaque and badly documented software
that I have ever had to deal with, which is why it is running in permissive
mode at the moment.


Well what I know about SELinux would fit in the navel of a flea(tip of 
the hat to David Niven), so I can not be of much help there. The reason 
I am returned this thread to the list, there are folks that do 
understand it.




Regards,

John



Thanks in advance.

John
=



--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Unable to connect to Postgresql

[Adrian Klaver]

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 last time you could connect and has anything of note 
happened since then?




Regards,

John
===
On Friday 07 April 2017 18:51:33 Adrian Klaver 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 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 1797:tid
140599445419776] [client 192.168.1.10:45127] PHP Warning:
pg_connect(): Unable to connect to PostgreSQL server: could not
connect to server: No such file or directory\n\tIs the server running
locally and
accepting\n\tconnections on Unix domain socket
/tmp/.s.PGSQL.5432? in /httpd/iliffe/testfcgi.php on line
121 

The proper socket does exist:

-
ls -al /tmp | grep PGSQL
srwxrwxrwx.  1 postgres postgres0 Apr  7 16:53 .s.PGSQL.5432
-rw---.  1 postgres postgres   49 Apr  7 16:53 .s.PGSQL.5432.lock

ss -a | grep 5432
u_str  LISTEN 0  128/tmp/.s.PGSQL.5432 30480
 * 0 -

Running on Fedora 25 with SELinux in PERMISSIVE mode.  The audit log
shows no hits on Postgresql.

Postgresql version number is 9.6.2

As expected, the postgresql log shows nothing since the last start up.


Well the last time this happened the answer was this:

https://www.postgresql.org/message-id/25543.1489081789%40sss.pgh.pa.us


Thanks in advance.

John
=





--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Unable to connect to Postgresql

[John Iliffe]

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 Friday 07 April 2017 18:51:33 Adrian Klaver 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 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 1797:tid
> > 140599445419776] [client 192.168.1.10:45127] PHP Warning: 
> > pg_connect(): Unable to connect to PostgreSQL server: could not
> > connect to server: No such file or directory\n\tIs the server running
> > locally and
> > accepting\n\tconnections on Unix domain socket
> > /tmp/.s.PGSQL.5432? in /httpd/iliffe/testfcgi.php on line
> > 121 
> > 
> > The proper socket does exist:
> > 
> > -
> > ls -al /tmp | grep PGSQL
> > srwxrwxrwx.  1 postgres postgres0 Apr  7 16:53 .s.PGSQL.5432
> > -rw---.  1 postgres postgres   49 Apr  7 16:53 .s.PGSQL.5432.lock
> > 
> > ss -a | grep 5432
> > u_str  LISTEN 0  128/tmp/.s.PGSQL.5432 30480  
> >  * 0 -
> > 
> > Running on Fedora 25 with SELinux in PERMISSIVE mode.  The audit log
> > shows no hits on Postgresql.
> > 
> > Postgresql version number is 9.6.2
> > 
> > As expected, the postgresql log shows nothing since the last start up.
> 
> Well the last time this happened the answer was this:
> 
> https://www.postgresql.org/message-id/25543.1489081789%40sss.pgh.pa.us
> 
> > Thanks in advance.
> > 
> > John
> > =


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Unable to connect to Postgresql

[Adrian Klaver]

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 17:03:28.597101 2017] [php7:warn] [pid 1797:tid
140599445419776] [client 192.168.1.10:45127] PHP Warning:  pg_connect():
Unable to connect to PostgreSQL server: could not connect to server: No
such file or directory\n\tIs the server running locally and
accepting\n\tconnections on Unix domain socket
/tmp/.s.PGSQL.5432? in /httpd/iliffe/testfcgi.php on line 121


The proper socket does exist:

-
ls -al /tmp | grep PGSQL
srwxrwxrwx.  1 postgres postgres0 Apr  7 16:53 .s.PGSQL.5432
-rw---.  1 postgres postgres   49 Apr  7 16:53 .s.PGSQL.5432.lock

ss -a | grep 5432
u_str  LISTEN 0  128/tmp/.s.PGSQL.5432 30480* 0
-

Running on Fedora 25 with SELinux in PERMISSIVE mode.  The audit log shows
no hits on Postgresql.

Postgresql version number is 9.6.2

As expected, the postgresql log shows nothing since the last start up.


Meant to add to previous post:

What happens if you try to connect to the database using psql?



Thanks in advance.

John
=





--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Unable to connect to Postgresql

[Adrian Klaver]

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 17:03:28.597101 2017] [php7:warn] [pid 1797:tid
140599445419776] [client 192.168.1.10:45127] PHP Warning:  pg_connect():
Unable to connect to PostgreSQL server: could not connect to server: No
such file or directory\n\tIs the server running locally and
accepting\n\tconnections on Unix domain socket
/tmp/.s.PGSQL.5432? in /httpd/iliffe/testfcgi.php on line 121


The proper socket does exist:

-
ls -al /tmp | grep PGSQL
srwxrwxrwx.  1 postgres postgres0 Apr  7 16:53 .s.PGSQL.5432
-rw---.  1 postgres postgres   49 Apr  7 16:53 .s.PGSQL.5432.lock

ss -a | grep 5432
u_str  LISTEN 0  128/tmp/.s.PGSQL.5432 30480* 0
-

Running on Fedora 25 with SELinux in PERMISSIVE mode.  The audit log shows
no hits on Postgresql.

Postgresql version number is 9.6.2

As expected, the postgresql log shows nothing since the last start up.


Well the last time this happened the answer was this:

https://www.postgresql.org/message-id/25543.1489081789%40sss.pgh.pa.us



Thanks in advance.

John
=





--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Unable to connect to Postgresql

[John Iliffe]

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 1797:tid 
140599445419776] [client 192.168.1.10:45127] PHP Warning:  pg_connect(): 
Unable to connect to PostgreSQL server: could not connect to server: No 
such file or directory\n\tIs the server running locally and 
accepting\n\tconnections on Unix domain socket 
/tmp/.s.PGSQL.5432? in /httpd/iliffe/testfcgi.php on line 121


The proper socket does exist:

-
ls -al /tmp | grep PGSQL
srwxrwxrwx.  1 postgres postgres0 Apr  7 16:53 .s.PGSQL.5432
-rw---.  1 postgres postgres   49 Apr  7 16:53 .s.PGSQL.5432.lock

ss -a | grep 5432
u_str  LISTEN 0  128/tmp/.s.PGSQL.5432 30480* 0 
-

Running on Fedora 25 with SELinux in PERMISSIVE mode.  The audit log shows 
no hits on Postgresql.

Postgresql version number is 9.6.2

As expected, the postgresql log shows nothing since the last start up.  

Thanks in advance.

John
=


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] SELECT and RowExclusiveLock

[David G. Johnston]

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 UPDATE;

SELECT function_that_performs_updates();

There are some more moving parts here, especially transactions, that may be
coming into play.  Its hard to say more given the limited and partial
detail.  Version and a more complete pg_stat_activity query would be
helpful.

David J.

Re: [GENERAL] SELECT and RowExclusiveLock

[Adrian Klaver]

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
--+---+--+-
 sales_transaction_detail |   392 | RowExclusiveLock | t
 sales_transaction_detail | 19077 | RowExclusiveLock | t
 sales_transaction_header | 32661 | RowExclusiveLock | t
 sales_transaction_header |   392 | RowExclusiveLock | t
 sales_transaction_header | 19077 | RowExclusiveLock | t

  pid  |   age| usename  |
 query
---+--+--+--
 32661 | -07:42:39.289945 | postgres | UPDATE "sales_transaction_header"
SET "create_datetime" = '2017-04-07T02:20:39.4
 19077 | -07:42:15.976288 | postgres | SELECT "price_benefit"."id",
"price_benefit"."create_datetime", "price_benefit".
   392 | -07:01:44.121346 | postgres | SELECT "price_benefit"."id",
"price_benefit"."create_datetime", "price_benefit".


It would help to have:

1) Schema definitions for sales_transaction_detail and 
sales_transaction_header


2) The complete queries.

3) And just for grins the Postgres version.


--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] SELECT and RowExclusiveLock

[Tim Nelson]

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
--+---+--+-
 sales_transaction_detail |   392 | RowExclusiveLock | t
 sales_transaction_detail | 19077 | RowExclusiveLock | t
 sales_transaction_header | 32661 | RowExclusiveLock | t
 sales_transaction_header |   392 | RowExclusiveLock | t
 sales_transaction_header | 19077 | RowExclusiveLock | t

  pid  |   age| usename  |
 query
---+--+--+--
 32661 | -07:42:39.289945 | postgres | UPDATE "sales_transaction_header"
SET "create_datetime" = '2017-04-07T02:20:39.4
 19077 | -07:42:15.976288 | postgres | SELECT "price_benefit"."id",
"price_benefit"."create_datetime", "price_benefit".
   392 | -07:01:44.121346 | postgres | SELECT "price_benefit"."id",
"price_benefit"."create_datetime", "price_benefit".

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

[Thorsten Glaser]

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 a trigger to the customer Right Now™
so I’ll fix this actual schema bug. I still find the CHECK constraint
to be a more natural way to express what I want, though.

I’m attaching the trigger conversion to help anyone else who does this
(and to invite feedback should there be anything I could improve).

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

testcase.sql
Description: application/sql

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

[Guillaume Lelarge]

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 that column. so in that
example, I
> think table size and index size should be equal. Why these are not equal?

If I understand correctly, the table only has 1 (integer) column and
all those 1,400,000 rows have the same value?


That's what I also understood.




Then the table has to store each row separately and thus has to store
the same value repeatedly. It also has to store some meta-data, such
as visibility information.


The meta data is the important stuff here. You have around seven system
columns for each row, bringing the row size from a mere 4 bytes to
something a bit more than 30 bytes.


The index on the other hand (assuming a btree index) knows that there
is only a single value in the table and therefore only stores a single
value, but it has to reference each row in the table that contains
that value.


Not true for a btree index. The value is stored as many times as it appears
on the table.

True on a gin index IIRC




So the table and the index are storing different things, but the total
size of each row/index node for that single integer column is of the
same order of magnitude. That's why they are similar in size.

If you would add another integer column to your table and VACUUM FULL
the table, the table would be about double its size, but the index
would stay the same size.


The table wouldn't double in size. It would grow but not that much. Though
I agree the index would stay the same.


Regards,
Alban.


> On Wed, Apr 5, 2017 at 1:02 PM, Steven Chang 
> wrote:
>>
>> Hello,
>>
>> try pgstattuple() and pgstatindex() , I think you will figure it out.
>>
>> Steven
>>
>> 2017-04-05 16:56 GMT+08:00 Guillaume Lelarge :
>>>
>>> Hi,
>>>
>>> 2017-04-05 9:44 GMT+02:00 Günce Kaya :

 Hi all,

 I have some questions about calculating table and index size.

 I have a dummy table which has an integer column and its index. The
 table has 140 rows and all of rows are same thats value is
2000.
 Table size is 50MB and index size is 31MB. Why there is too much size
 difference between table and its index? what happen on data files when
we
 add index?

>>>
>>> You have metadata informations in the table datafiles that you don't
have
>>> on the index datafiles. For example, all the system columns for each
line.
>>>

 Second question is that after created table, table size was 0 byte. I
 inserted a row as 120 then table size was 8192 byte. I inserted five
times
 same value to the table and table size is still 8192 bytes. Table size
 changed after inserted lots of rows. Table size was stabile till first
few
 hundred rows. why table size didn't change when I inserted lots of
rows?

>>>
>>> PostgreSQL works with 8KB blocks. When you insert a line, it puts it on
a
>>> block, but this block may contain many lines. So your next new lines
still
>>> fit in the first block... until it doesn't, and you'll see a new block
>>> coming, making your table datafile grows to 16KB. And so on and so on.
>>>
>>>
>>> --
>>> Guillaume.
>>>   http://blog.guillaume.lelarge.info
>>>   http://www.dalibo.com
>>
>>
>
>
>
> --
> Gunce Kaya
>
> Linkedin - Twitter - Blog



--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.

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

[Alban Hertroys]

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 should be equal. Why these are not equal?

If I understand correctly, the table only has 1 (integer) column and
all those 1,400,000 rows have the same value?

Then the table has to store each row separately and thus has to store
the same value repeatedly. It also has to store some meta-data, such
as visibility information.

The index on the other hand (assuming a btree index) knows that there
is only a single value in the table and therefore only stores a single
value, but it has to reference each row in the table that contains
that value.

So the table and the index are storing different things, but the total
size of each row/index node for that single integer column is of the
same order of magnitude. That's why they are similar in size.

If you would add another integer column to your table and VACUUM FULL
the table, the table would be about double its size, but the index
would stay the same size.

Regards,
Alban.


> On Wed, Apr 5, 2017 at 1:02 PM, Steven Chang 
> wrote:
>>
>> Hello,
>>
>> try pgstattuple() and pgstatindex() , I think you will figure it out.
>>
>> Steven
>>
>> 2017-04-05 16:56 GMT+08:00 Guillaume Lelarge :
>>>
>>> Hi,
>>>
>>> 2017-04-05 9:44 GMT+02:00 Günce Kaya :

 Hi all,

 I have some questions about calculating table and index size.

 I have a dummy table which has an integer column and its index. The
 table has 140 rows and all of rows are same thats value is 2000.
 Table size is 50MB and index size is 31MB. Why there is too much size
 difference between table and its index? what happen on data files when we
 add index?

>>>
>>> You have metadata informations in the table datafiles that you don't have
>>> on the index datafiles. For example, all the system columns for each line.
>>>

 Second question is that after created table, table size was 0 byte. I
 inserted a row as 120 then table size was 8192 byte. I inserted five times
 same value to the table and table size is still 8192 bytes. Table size
 changed after inserted lots of rows. Table size was stabile till first few
 hundred rows. why table size didn't change when I inserted lots of rows?

>>>
>>> PostgreSQL works with 8KB blocks. When you insert a line, it puts it on a
>>> block, but this block may contain many lines. So your next new lines still
>>> fit in the first block... until it doesn't, and you'll see a new block
>>> coming, making your table datafile grows to 16KB. And so on and so on.
>>>
>>>
>>> --
>>> Guillaume.
>>>   http://blog.guillaume.lelarge.info
>>>   http://www.dalibo.com
>>
>>
>
>
>
> --
> Gunce Kaya
>
> Linkedin - Twitter - Blog



-- 
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] A change in the Debian install

[Joshua D. Drake]

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 decisions is many
miles south of abysmal.  So you might look at whatever patches
are in the Debian package to see if there's anything touching
pgstat.c's socket-setup logic.)



Wow Tom, FUD much?

Let's remember that the .Deb folks are .Org members are try very hard to 
create quality packages that are of production quality.


JD


regards, tom lane





--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] keeping WAL after dropping replication slots

[Adrian Klaver]

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

>>:

On 04/04/2017 07:45 AM, Tom DalPozzo wrote:

Postgres version?

9.6.1


Hi,
I had two replication slots on my primary. Slaves off and
(around 800)
WALs kept as expected.


Slaves off means?:


You replication set up from the master to the slaves(how many?).
Then you disconnected the slaves how?

I have 2 slaves configured with async replication but they were down
 when I dropped the slots.

So the 800 WALs number mean you have wal_keep_segments set
to 800?

No,  wal_keep_segments is commented.
800 is the rough number of files I saw in xlog dir before
dropping the
slots.


What are your settings for?:

archive_mode

archive_mode is off


archive_command

it's set as I tested it some months ago but now archive_mode is off


Do you see anything in the Postgres log that might apply?

No, nothing


I am not sure what is going on.

Are the number of WAL files still growing?


--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] A change in the Debian install

[Christoph Berg]

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-
> > > 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 decisions is many
> > > miles south of abysmal.  So you might look at whatever patches
> > > are in the Debian package to see if there's anything touching
> > > pgstat.c's socket-setup logic.)
> >
> > I don't believe this is really a fair assessment.  Maybe at some point
> > in the distant past, but not today.  Christoph is regularly on this list
> > contributing to threads regarding packaging, submitting patches of his
> > own for improvements to PG, and the patches currently included in the
> > Debian distribution, at least mostly, are for things which really should
> > be possible to do with configure options, but which we don't provide
> > today, or things we should just be handling already.
> >
> 
> +1. While this may have been true in a *very* distant past, it's certainly
> not anymore. So let's try to avoid spreading disinformation about that.
> 
> And FWIW, the RPM distributions have about the same number of patches...

Thanks Stephen and Magnus. I don't think the way Martin and I have
been handling the Debian packages over the last year deserves being
bashed that loudly. At least I would expect a Cc on such matters, Tom
should know very well whom to address here.

> > 51-default-sockets-in-var.patch
> >   Use /var/run/postgresql/ for the DEFAULT_PGSOCKET_DIR.  We really
> >   should allow this to be changed in configure.
> 
> This looks exactly like something the RPMs want as well, so we should
> definitely look at providing that upstream.

That one is touching src/include/pg_config_manual.h only, i.e.
something that is actually meant to be altered.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/51-default-sockets-in-var.patch?h=10

> I'll start a discussion with Christoph on if we might, already, be able
> > to remove some of these, and where we might be able to make upstream
> > changes to remove the need for others.
> 
> That'd be useful. I think you should also include Devrim to figure out what
> things would actually make *both* sides happier.

Aye.


Re: Stephen Frost 2017-04-06 <20170406134629.gt9...@tamriel.snowman.net>
> The non-comment/documentation patches include for the Debian PG 9.6
> packages are:
> 
> 50-per-version-dirs.patch
>   Use version specific installation directories so that several major
>   versions can be installed in parallel.  This includes changing
>   pkglibdir and includedir_server.  Those might be able to be set
>   through existing configure flags and that's probably something we
>   could work with Christoph to do.

Nod. If someone figures how to translate that to configure (or
possibly make) arguments, I'd be happy to move to using that.

>   There's also a change to pg_config
>   which might be a bit more difficult to handle in upstream (related to
>   how pg_config ends up in /usr/bin, but that isn't the "right" BINDIR).

pg_config is special there, because we ship it twice, once in
/usr/bin/ libpq-dev, and then again in
/usr/lib/postgresql/$version/bin/ from postgresql-server-dev-version.
Not sure if there's a saner approach that still allows co-installation
of multiple versions, while still supplying a pg_config from libpq-dev
that allows using --includedir and other version-independent queries.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/50-per-version-dirs.patch?h=10

> 54-debian-alternatives-for-external-tools.patch
>   Use 'sensible-editor' for DEFAULT_EDITOR, and 'pager' for
>   DEFAULT_PAGER.  These could also be done through configure switches, I
>   would think.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/54-debian-alternatives-for-external-tools.patch?h=10

> 64-pg_upgrade-sockdir
>   This is a bit of a curious one, the description is:
>   Fix for: connection to database failed: Unix-domain socket path
>   
> "/build/buildd-postgresql-9.3_9.3~beta1-1-i386-mHjRUH/postgresql-9.3-9.3~beta1/build/contrib/pg_upgrade/.s.PGSQL.50432"
>   is too long (maximum 107 bytes)
> 
>   See also: http://lists.debian.org/debian-wb-team/2013/05/msg00015.html
> 
>   This basically adds a mechanism to fall back to using /tmp if the
>   socket path is too long.  Would probably be good to figure out a
>   better way.

That one is actually on my TODO list:
https://www.postgresql.org/message-id/20140711094009.GB3115%40msg.df7cb.de
I'll need to restart working on it.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/64-pg_upgrade-sockdir?h=10

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

[Günce Kaya]

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 clear. Thanks for your both of
answers.

Steven, thanks for your response. I got a new information thanks to you.

Regards,

Gunce Kaya


On Wed, Apr 5, 2017 at 1:02 PM, Steven Chang 
wrote:

> Hello,
>
> try pgstattuple() and pgstatindex() , I think you will figure it out.
>
> Steven
>
> 2017-04-05 16:56 GMT+08:00 Guillaume Lelarge :
>
>> Hi,
>>
>> 2017-04-05 9:44 GMT+02:00 Günce Kaya :
>>
>>> Hi all,
>>>
>>> I have some questions about calculating table and index size.
>>>
>>> I have a dummy table which has an integer column and its index. The
>>> table has 140 rows and all of rows are same thats value is 2000.
>>> Table size is 50MB and index size is 31MB. Why there is too much size
>>> difference between table and its index? what happen on data files when we
>>> add index?
>>>
>>>
>> You have metadata informations in the table datafiles that you don't have
>> on the index datafiles. For example, all the system columns for each line.
>>
>>
>>> Second question is that after created table, table size was 0 byte. I
>>> inserted a row as 120 then table size was 8192 byte. I inserted five times
>>> same value to the table and table size is still 8192 bytes. Table size
>>> changed after inserted lots of rows. Table size was stabile till first few
>>> hundred rows. why table size didn't change when I inserted lots of rows?
>>>
>>>
>> PostgreSQL works with 8KB blocks. When you insert a line, it puts it on a
>> block, but this block may contain many lines. So your next new lines still
>> fit in the first block... until it doesn't, and you'll see a new block
>> coming, making your table datafile grows to 16KB. And so on and so on.
>>
>>
>> --
>> Guillaume.
>>   http://blog.guillaume.lelarge.info
>>   http://www.dalibo.com
>>
>
>


-- 
Gunce Kaya

Linkedin  - Twitter
 - Blog

Re: [GENERAL] keeping WAL after dropping replication slots

[Chris Mair]

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 list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] keeping WAL after dropping replication slots

[Tom DalPozzo]

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:
>>
>> Postgres version?
>>
>> 9.6.1
>>
>>
>> Hi,
>> I had two replication slots on my primary. Slaves off and
>> (around 800)
>> WALs kept as expected.
>>
>>
>> Slaves off means?:
>>
>>
>> You replication set up from the master to the slaves(how many?).
>> Then you disconnected the slaves how?
>>
>> I have 2 slaves configured with async replication but they were down
>>  when I dropped the slots.
>>
>> So the 800 WALs number mean you have wal_keep_segments set to 800?
>>
>> No,  wal_keep_segments is commented.
>> 800 is the rough number of files I saw in xlog dir before dropping the
>> slots.
>>
>
> What are your settings for?:
>
> archive_mode
>
archive_mode is off


> archive_command
>
it's set as I tested it some months ago but now archive_mode is off


> Do you see anything in the Postgres log that might apply?
>
No, nothing


>
>>
>>
>>
>> I dropped those slots but over time, the system kept on adding
>> new WALs
>> without reusing them or deleting them.
>> Only after shutdown and restart the system deleted those WAL
>> files.
>> Is that ok?
>> regards
>> Pupillo
>>
>>
>>
>>
>> --
>> Adrian Klaver
>> adrian.kla...@aklaver.com 
>>
>>
>> Regards
>> Pupillo
>>
>> Thanks
Pupillo