[GENERAL] phpPgAdmin 6 on a MAC (High Sierra)

2017-10-06 Thread Jerry Levan 
Apple has added PostgreSQL support to php in High Sierra. PhpPgAdmin seems to 
have died at Version 5.1 and it does not play nice with php 7.x. There is a 
fork called phpPgAdmin 6.

I have been able to get the interface up but selecting a database results in an 
error. 

My php-foo is weak...has anyone been to get phpPgAdmin working on a Mac running 
High Sierra?

Thanks for any info...

Trapped in Steve Jobs Reality Distortion Field

-- 
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] Functions and Parentheses

2017-10-06 Thread Igal @ Lucee.org 

On 10/6/2017 3:10 PM, Joshua D. Drake wrote:

On 10/06/2017 02:33 PM, Tom Lane wrote:

"Igal @ Lucee.org"  writes:
How come `current_date` has no parenthesis but `clock_timestamp()` 
does?


Because the SQL standard says that CURRENT_DATE doesn't have 
parentheses.

It is a function by any other measure, though.

(AFAICT, the SQL committee is unacquainted with any principles of
programming language syntax design that emerged later than the COBOL
era.  Their capacity to invent new and non-orthogonal syntax for every
new feature seems boundless.)


This is the best statement I have read all week.


+1

I also want to say that I'm using many different open source projects, 
but Postgres has by far the best community support of all, not to 
mention a product that is far superior to the many commercial 
alternatives in the market.


It's kind of like -- I can use Postgres for free, or I can spend a lot 
of money and get an inferior product with inferior support.


If Postgres had been written in Java then I'd be much more involved, but 
my C/C++ skills are rather limited.


Anyway, great job guys!  And Thank you!

Igal Sapir
Lucee Core Developer
Lucee.org

Re: [GENERAL] Functions and Parentheses

2017-10-06 Thread Joshua D. Drake 

On 10/06/2017 02:33 PM, Tom Lane wrote:

"Igal @ Lucee.org"  writes:

How come `current_date` has no parenthesis but `clock_timestamp()` does?


Because the SQL standard says that CURRENT_DATE doesn't have parentheses.
It is a function by any other measure, though.

(AFAICT, the SQL committee is unacquainted with any principles of
programming language syntax design that emerged later than the COBOL
era.  Their capacity to invent new and non-orthogonal syntax for every
new feature seems boundless.)


This is the best statement I have read all week.

JD




regards, tom lane





--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc

PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
* Unless otherwise stated, opinions are my own.   *


--
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] Functions and Parentheses

2017-10-06 Thread Tom Lane 
"Igal @ Lucee.org"  writes:
> How come `current_date` has no parenthesis but `clock_timestamp()` does?

Because the SQL standard says that CURRENT_DATE doesn't have parentheses.
It is a function by any other measure, though.

(AFAICT, the SQL committee is unacquainted with any principles of
programming language syntax design that emerged later than the COBOL
era.  Their capacity to invent new and non-orthogonal syntax for every
new feature seems boundless.)

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] Functions and Parentheses

2017-10-06 Thread David G. Johnston 
On Fri, Oct 6, 2017 at 2:18 PM, Igal @ Lucee.org  wrote:

> Hi,
>
> Is current_date a function?  It's a bit puzzling to me since there are no
> parentheses after it, i.e.
>
>   SELECT current_date;
>
> And not
>
>   SELECT current_date();  -- syntax error
>
​
It, and the others like it, behave as functions.  They don't require
parentheses because the SQL standard​
​
​ defines them without parentheses.

> How come `current_date` has no parenthesis but `clock_timestamp()` does?
>
clock_timestamp isn't standard defined and unless the standard forces us to
do otherwise function invocation requires parentheses.

See 9.9.4 (
https://www.postgresql.org/docs/9.6/static/functions-datetime.html )

David J.

[GENERAL] Functions and Parentheses

2017-10-06 Thread Igal @ Lucee.org 

Hi,

Is current_date a function?  It's a bit puzzling to me since there are 
no parentheses after it, i.e.


  SELECT current_date;

And not

  SELECT current_date();  -- syntax error

How come `current_date` has no parenthesis but `clock_timestamp()` does?

Thanks,

Igal Sapir
Lucee Core Developer
Lucee.org

Re: [GENERAL] Strange checkpoint behavior - checkpoints take a long time

2017-10-06 Thread Vladimir Nicolici 
Further updates:

Yesterday checkpoints were finishing more or less on time with the 
configuration for 25 minutes out of 30 minutes, taking 26 minutes at most.

So for today I reduced the time reserved for checkpoint writes to 20 minutes 
out of 30 minutes, by setting checkpoint_completion_target to 0.66 instead of 
0.83, and I disabled the bgwriter completely by setting bgwriter_lru_maxpages 
from 100 to 0. 

I expected this might cause the checkpoints to take more time, and not finish 
in 20 minutes, but that didn’t happen.

For the first part of the day, when the activity was lower, checkpoints 
finished almost on time, less than 30 seconds more than configured:

2017-10-06 10:30:56.248 EDT [4927] LOG:  checkpoint starting: time
2017-10-06 10:51:26.227 EDT [4927] LOG:  checkpoint complete: wrote 4364979 
buffers (23.1%); 0 transaction log file(s) added, 0 removed, 1936 recycled; 
write=1187.940 s, sync=1.888 s, total=1229.979 s; sync files=744, longest=0.041 
s, average=0.002 s; distance=31073898 kB, estimate=32879405 kB

Then later, as the activity increased, something I didn’t expect happened. The 
checkpoints started to finish much sooner than configured, in 16:38 minutes 
instead of 20 minutes, so 3:22 minutes earlier than configured:

2017-10-06 11:00:56.347 EDT [4927] LOG:  checkpoint starting: time
2017-10-06 11:17:34.778 EDT [4927] LOG:  checkpoint complete: wrote 5376422 
buffers (28.5%); 0 transaction log file(s) added, 0 removed, 1897 recycled; 
write=959.908 s, sync=1.578 s, total=998.431 s; sync files=772, longest=0.045 
s, average=0.002 s; distance=37712624 kB, estimate=37712624 kB

Then, even stranger, the next checkpoint started sooner than configured, by 
2:11 minutes, with the reason “xlog” instead of “time”:

2017-10-06 11:27:48.754 EDT [4927] LOG:  checkpoint starting: xlog
2017-10-06 11:42:00.131 EDT [4927] LOG:  checkpoint complete: wrote 6123787 
buffers (32.4%); 0 transaction log file(s) added, 239 removed, 2063 recycled; 
write=806.887 s, sync=1.032 s, total=851.377 s; sync files=767, longest=0.052 
s, average=0.001 s; distance=40254253 kB, estimate=40254253 kB

All subsequent checkpoints for the rest of the day look similar, they start 
with the reason “xlog”, and finish in around 15 minutes each instead of 20, and 
the time between two checkpoint starts is around 25 minutes instead of 30.

I’m not sure what causes these early finishes and early starts. The checkpoint 
start message is not very helpful in determining why it started early, in my 
opinion. It’s saying “xlog”, but a more verbose description, maybe even 
including some numbers it based its decision to start the checkpoint on, would 
be more helpful.

I’m guessing the reason for starting a checkpoint is that it estimated the 96 
GB reserved with max_wal_size would be filled unless it starts a checkpoint 
earlier than configured. I’ll increase the max_wal_size from 96 GB to 144 GB 
for Monday, to see if it changes this behavior.

Thanks,
Vlad

Re: [GENERAL] delete a file everytime pg server starts/crashes

2017-10-06 Thread pinker 
Actually if the name of the file doesn't matter you could put it into
$PGDATA/pg_stat and name it global.stat. When postgres stops (clean or
because of failure), replaces the file with his own. So your content will be
erased.
I'm not sure it's completely safe but works in simple test.



--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html


-- 
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] Postgresql CDC tool recommendations ?

2017-10-06 Thread Nico Williams 
On Thu, Oct 05, 2017 at 10:28:31AM -0700, avi Singh wrote:
>  Any recommendation on a good CDC tool that can be used to push
> postgresql changes to Kafka in json format ?

There are quite a few WAL->JSON type tools out there.  E.g.,
https://github.com/eulerto/wal2json

I expect this to improve with PG 10 logical replication.

You can easily add the bit that pushes those JSON texts to Kafka.

Nico
-- 


-- 
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] delete a file everytime pg server starts/crashes

2017-10-06 Thread pinker 
Look at inotify: https://github.com/rvoicilas/inotify-tools
You can check for instance if postmaster.pid exists.



--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html


-- 
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] compiling postgres_fdw fails for 9.6.5

2017-10-06 Thread Tom Lane 
Sandeep Gupta  writes:
> I downloaded the source, configured it with prefix=install_dir and
> then moved to contrib/postgres_fdw dir.
> However make fails with following error:
> ../../src/include/utils/elog.h:71:28: fatal error: utils/errcodes.h:
> No such file or directory

Try building the core code first.

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

[GENERAL] Connection utilisation for pglogical

2017-10-06 Thread Rory Campbell-Lange 
Ahead of setting up a testing environment to tryout pglogical, I'm keen
to learn of the connection requirements for pglogical publisher and
subscribers.

Our use case is a cluster of (say) 200 databases, and we would like to
look into aggregating data from a certain table using a row filter hook
into a central database, possibly in a remote cluster, for further
processing.

Based on the docs at https://github.com/2ndQuadrant/pglogical, the
configuration parameters appear to be:

wal_level = 'logical'
max_worker_processes = 10   # one per database needed on provider node
# one per node needed on subscriber node
max_replication_slots = 10  # one per node needed on provider node
max_wal_senders = 10# one per node needed on provider node
shared_preload_libraries = 'pglogical'

So presumably in my example I assume we need 200 max_worker_processes,
200 max_replication_slots and 200 max_wal_senders? Does this translate
into 200 actual database connections?

Thanks for any advice
Rory




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

[GENERAL] compiling postgres_fdw fails for 9.6.5

2017-10-06 Thread Sandeep Gupta 
Hello,

I am on Cent OS 6.8 machine. The Postgres is already installed in some
install_dir/.
I downloaded the source, configured it with prefix=install_dir and
then moved to contrib/postgres_fdw dir.
However make fails with following error:

gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -O2 -fPIC
-I../../src/interfaces/libpq -I. -I. -I../../src/include -D_GNU_SOURCE
  -c -o postgres_fdw.o postgres_fdw.c
In file included from ../../src/include/postgres.h:48:0,
 from postgres_fdw.c:13:
../../src/include/utils/elog.h:71:28: fatal error: utils/errcodes.h:
No such file or directory
compilation terminated.
make: *** [postgres_fdw.o] Error 1


It gets fixed if I add
-I[install_dir]/include/postgresql/server.

Is there alternative way which would not require this modification.

Thanks.


-- 
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] Regarding scram authentication libpq version 10 or more

2017-10-06 Thread Durgamahesh Manne 
On Fri, Oct 6, 2017 at 5:56 PM, Michael Paquier 
wrote:

> On Fri, Oct 6, 2017 at 8:56 PM, Durgamahesh Manne
>  wrote:
> > i have already read complete info about New Postgres 10 in postgres.org
> and
> > i have tried to access server  by adding the
> > scram-sha-256 authentication in hba.conf and also have already set
> > password_encyption = scram-sha-256 in config then reloaded the server for
> > multiple times
> >
> > still i am getting same error i given you earlier while i check to
> access pg
> > server with required credentials
> >
> > psql.bin: SCRAM authentication requires libpq version 10 or above
>
> No idea. You may be using multiple versions of PostgreSQL in parallel,
> and the client you are using may not be the client you think it is. I
> suggest that you check the infrastructure of your host as well as the
> package repository you are using. Good luck.
> --
> Michael
>



as per the above email conversation


 Yes sir . i am using multiple versions of postgresql .i found solution for
this error. libpq error repeats when i have  tried to access pg server from
older than postgres version 10 . so however i have installed postgresql 10
in linuxss then i have accessed to (pg10) pg server with psql from
postgresql 10 version only



Regards
durgamahesh m

Re: [GENERAL] Regarding scram authentication libpq version 10 or more

2017-10-06 Thread Michael Paquier 
On Fri, Oct 6, 2017 at 8:56 PM, Durgamahesh Manne
 wrote:
> i have already read complete info about New Postgres 10 in postgres.org  and
> i have tried to access server  by adding the
> scram-sha-256 authentication in hba.conf and also have already set
> password_encyption = scram-sha-256 in config then reloaded the server for
> multiple times
>
> still i am getting same error i given you earlier while i check to access pg
> server with required credentials
>
> psql.bin: SCRAM authentication requires libpq version 10 or above

No idea. You may be using multiple versions of PostgreSQL in parallel,
and the client you are using may not be the client you think it is. I
suggest that you check the infrastructure of your host as well as the
package repository you are using. Good luck.
-- 
Michael


-- 
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] Regarding scram authentication libpq version 10 or more

2017-10-06 Thread Durgamahesh Manne 
On Fri, Oct 6, 2017 at 3:40 PM, Michael Paquier 
wrote:

> On Fri, Oct 6, 2017 at 5:44 PM, Durgamahesh Manne
>  wrote:
> > This is regarding scram authentication libpq version 10. From which
> site  i
> > can download to configure libpq in order to use scram authentication in
> > postgres 10
> >
> > i got below error while i check to access pg server
> >
> > psql.bin: SCRAM authentication requires libpq version 10 or more
> >
> > please let me know the detail info about scram libpq
>
> Why not beginning to look at the download page of postgresql.org? Here
> is the page:
> https://www.postgresql.org/download/
> SCRAM/SASL support in libpq is provided in any build of PostgreSQL 10,
> so this depends mainly on the distribution and environment you are
> using.
>
> In order to get support for SCRAM, the documentation provides enough
> details, beginning here:
> https://www.postgresql.org/docs/10/static/auth-methods.html#auth-password
> Basically you need to consider using password_encryption =
> 'scram-sha-256', and configure pg_hba.conf with a correct entry. If
> you are upgrading from an existing instance, you need to make sure
> that users with passwords are updated with proper SCRAM-hashed
> entries.
> --
> Michael
>



Hi sir

As per above mail conversation


i have already read complete info about New Postgres 10 in postgres.org
and i have tried to access server  by adding the
scram-sha-256 authentication in hba.conf and also have already set
password_encyption = scram-sha-256 in config then reloaded the server for
multiple times

still i am getting same error i given you earlier while i check to access
pg server with required credentials

psql.bin: SCRAM authentication requires libpq version 10 or above


i am using linux mint distrib

DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.1
DISTRIB_CODENAME=rebecca
DISTRIB_DESCRIPTION="Linux Mint 17.1 Rebecca"
::
/etc/os-release
::
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"


 Regards

durgamahesh m

Re: [GENERAL] Regarding scram authentication libpq version 10 or more

2017-10-06 Thread Michael Paquier 
On Fri, Oct 6, 2017 at 5:44 PM, Durgamahesh Manne
 wrote:
> This is regarding scram authentication libpq version 10. From which site  i
> can download to configure libpq in order to use scram authentication in
> postgres 10
>
> i got below error while i check to access pg server
>
> psql.bin: SCRAM authentication requires libpq version 10 or more
>
> please let me know the detail info about scram libpq

Why not beginning to look at the download page of postgresql.org? Here
is the page:
https://www.postgresql.org/download/
SCRAM/SASL support in libpq is provided in any build of PostgreSQL 10,
so this depends mainly on the distribution and environment you are
using.

In order to get support for SCRAM, the documentation provides enough
details, beginning here:
https://www.postgresql.org/docs/10/static/auth-methods.html#auth-password
Basically you need to consider using password_encryption =
'scram-sha-256', and configure pg_hba.conf with a correct entry. If
you are upgrading from an existing instance, you need to make sure
that users with passwords are updated with proper SCRAM-hashed
entries.
-- 
Michael


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

[GENERAL] Regarding scram authentication libpq version 10 or more

2017-10-06 Thread Durgamahesh Manne 
Hi sir

This is regarding scram authentication libpq version 10. From which site  i
can download to configure libpq in order to use scram authentication in
postgres 10

i got below error while i check to access pg server

psql.bin: SCRAM authentication requires libpq version 10 or more


please let me know the detail info about scram libpq


Regards

durgamahesh m

Re: [GENERAL] delete a file everytime pg server starts/crashes

2017-10-06 Thread vinny 
That seems like an odd requirement and I don't think PostgreSQL can do 
it itself,
because if postgresql should crash properly then the process that should 
write/remove that file would also crash


The simplest way would be to write a cronjob that connects to the 
database and does a simple query to see if things are ok,
and act accordingly. But cronjobs cannot be executed more than once a 
miunute so there would be a considerable delay.


If you need faster responses you may need to write a custom deamon or 
use something like supervisord to manage a long polling script.


I get the feeling there must be a more elegant solution to whatever your 
problem is though...


On 2017-10-05 16:04, athinivas wrote:

Hi,

I'm having a requirement to delete a file in system whenever pg server 
is

started/crashed. Any idea?

Thanks,
Athi



--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html



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