Re: [GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or later is required, but this is .

[Adrian Klaver]

On 10/24/2016 01:49 PM, John R Pierce wrote:

On 10/24/2016 1:19 PM, Andre Mikulec wrote:


May strait answer is true.


1. I need to change the width of all of my tables because I have very
wide data.  There is a compile-time parameter for that.

2. I need to debug, compile and install a modified version of the
PostgreSQL extension pl/r.


please don't reply to an existing thread with a completely new
topic. your questions have nothing to do with *"Subject:* Re:
[GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or later is
required, but this is ."


They do if there is no reason to do a custom compile. As it turns out 
there was a reason, so we return to regularly scheduled programing:)








--
john r pierce, recycling bits in santa cruz




--
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] configure PostgreSQL with PERL: Perl version 5.8 or later is required, but this is .

[Adrian Klaver]

On 10/24/2016 01:19 PM, Andre Mikulec wrote:


May strait answer is true.


1. I need to change the width of all of my tables because I have very
wide data.  There is a compile-time parameter for that.


Beyond my knowledge, but I understand the custom compile now.



2. I need to debug, compile and install a modified version of the
PostgreSQL extension pl/r.


Andre Mikulec
andre_miku...@hotmail.com





--
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] configure PostgreSQL with PERL: Perl version 5.8 or later is required, but this is .

[John R Pierce]

On 10/24/2016 1:19 PM, Andre Mikulec wrote:


May strait answer is true.


1. I need to change the width of all of my tables because I have very 
wide data.  There is a compile-time parameter for that.


2. I need to debug, compile and install a modified version of the 
PostgreSQL extension pl/r.


please don't reply to an existing thread with a completely new 
topic. your questions have nothing to do with *"Subject:* Re: 
[GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or later is 
required, but this is ."






--
john r pierce, recycling bits in santa cruz

Re: [GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or later is required, but this is .

[Andre Mikulec]

May strait answer is true.


1. I need to change the width of all of my tables because I have very wide 
data.  There is a compile-time parameter for that.

2. I need to debug, compile and install a modified version of the PostgreSQL 
extension pl/r.


Andre Mikulec
andre_miku...@hotmail.com



From: Adrian Klaver 
Sent: Monday, October 24, 2016 2:10 PM
To: Andre Mikulec; pgsql-general@postgresql.org
Cc: Tom Lane
Subject: Re: [GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or 
later is required, but this is .

On 10/24/2016 11:01 AM, Andre Mikulec wrote:
>
> Never mind.  I figured it out.
>
> Soon I will write up a summary.

What I am not understanding is why you are building from source and not
using the pre-built packages that:

BigSQL:

https://www.bigsql.org/postgresql/installers.jsp

PostgreSQL Installers by 
BigSQL
www.bigsql.org
PostgreSQL Installers. These enterprise-class 64-bit PostgreSQL binaries are 
always free and Open Source. They are tested to run on Centos 6+, Ubuntu 
12.04+, OSX 10.9 ...




or

EDB:

http://www.enterprisedb.com/products-services-training/pgdownload#windows

provide with their Windows binaries?

>
> Andre Mikulec
> andre_miku...@hotmail.com
>
>


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

Re: [GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or later is required, but this is .

[Adrian Klaver]

On 10/24/2016 11:01 AM, Andre Mikulec wrote:


Never mind.  I figured it out.

Soon I will write up a summary.


What I am not understanding is why you are building from source and not 
using the pre-built packages that:


BigSQL:

https://www.bigsql.org/postgresql/installers.jsp

or

EDB:

http://www.enterprisedb.com/products-services-training/pgdownload#windows

provide with their Windows binaries?



Andre Mikulec
andre_miku...@hotmail.com





--
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] Errors while installing PostGIS by an unusual method

[Ankit Sablok]

Thanks for replying Tom and Asif, I think the issue was that libpq.so
present in the /pgsql/lib directory did not have all its dependencies
installed on the system namely openssl hence I execute the command sudo yum
install openssl and that proceeded the configure script forward, but now I
ran into a separate issue where I do see libxml2 libraries present in the
/pgsql/lib directory and I have also set the appropriate PATH and
LD_LIBRARY_PATH for the build to happen successfully, here is the configure
log when I execute the following command

./configure --with-gdalconfig=/pgsql/bin/gdal-config
--with-geosconfig=//pgsql/bin/geos-config
--with-projdir=/pgsql --with-jsondir=/rdsdbbin/apg-1.0.6.2
--with-pgconfig=/pgsql/bin/pg_config --with-libxml2=/pgsql/bin/xml2-config

*configure: WARNING: unrecognized options: --with-libxml2*
*checking build system type... x86_64-unknown-linux-gnu*
*checking host system type... x86_64-unknown-linux-gnu*
*checking how to print strings... printf*
*checking for gcc... gcc*
*checking whether the C compiler works... yes*
*checking for C compiler default output file name... a.out*
*checking for suffix of executables... *
*checking whether we are cross compiling... no*
*checking for suffix of object files... o*
*checking whether we are using the GNU C compiler... yes*
*checking whether gcc accepts -g... yes*
*checking for gcc option to accept ISO C89... none needed*
*checking for a sed that does not truncate output... /bin/sed*
*checking for grep that handles long lines and -e... /bin/grep*
*checking for egrep... /bin/grep -E*
*checking for fgrep... /bin/grep -F*
*checking for ld used by gcc... /usr/bin/ld*
*checking if the linker (/usr/bin/ld) is GNU ld... yes*
*checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm*
*checking the name lister (/usr/bin/nm) interface... BSD nm*
*checking whether ln -s works... yes*
*checking the maximum length of command line arguments... 1572864*
*checking whether the shell understands some XSI constructs... yes*
*checking whether the shell understands "+="... yes*
*checking how to convert x86_64-unknown-linux-gnu file names to
x86_64-unknown-linux-gnu format... func_convert_file_noop*
*checking how to convert x86_64-unknown-linux-gnu file names to toolchain
format... func_convert_file_noop*
*checking for /usr/bin/ld option to reload object files... -r*
*checking for objdump... objdump*
*checking how to recognize dependent libraries... pass_all*
*checking for dlltool... no*
*checking how to associate runtime and link libraries... printf %s\n*
*checking for ar... ar*
*checking for archiver @FILE support... @*
*checking for strip... strip*
*checking for ranlib... ranlib*
*checking for gawk... gawk*
*checking command to parse /usr/bin/nm output from gcc object... ok*
*checking for sysroot... no*
*checking for mt... no*
*checking if : is a manifest tool... no*
*checking how to run the C preprocessor... gcc -E*
*checking for ANSI C header files... yes*
*checking for sys/types.h... yes*
*checking for sys/stat.h... yes*
*checking for stdlib.h... yes*
*checking for string.h... yes*
*checking for memory.h... yes*
*checking for strings.h... yes*
*checking for inttypes.h... yes*
*checking for stdint.h... yes*
*checking for unistd.h... yes*
*checking for dlfcn.h... yes*
*checking for objdir... .libs*
*checking if gcc supports -fno-rtti -fno-exceptions... no*
*checking for gcc option to produce PIC... -fPIC -DPIC*
*checking if gcc PIC flag -fPIC -DPIC works... yes*
*checking if gcc static flag -static works... no*
*checking if gcc supports -c -o file.o... yes*
*checking if gcc supports -c -o file.o... (cached) yes*
*checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports
shared libraries... yes*
*checking whether -lc should be explicitly linked in... no*
*checking dynamic linker characteristics... GNU/Linux ld.so*
*checking how to hardcode library paths into programs... immediate*
*checking whether stripping libraries is possible... yes*
*checking if libtool supports shared libraries... yes*
*checking whether to build shared libraries... yes*
*checking whether to build static libraries... yes*
*checking for gcc... (cached) gcc*
*checking whether we are using the GNU C compiler... (cached) yes*
*checking whether gcc accepts -g... (cached) yes*
*checking for gcc option to accept ISO C89... (cached) none needed*
*checking how to run the C preprocessor... gcc -E*
*checking for grep that handles long lines and -e... (cached) /bin/grep*
*checking for ant... no*
*checking for cpp... /usr/local/bin/cpp*
*checking if gcc supports -Wall... yes*
*checking if gcc supports -Wmissing-prototypes... yes*
*checking if gcc supports -ffloat-store... yes*
*checking if gcc supports --exclude-libs... yes*
*checking for flex... flex*
*checking lex output file root... lex.yy*
*checking lex library... none needed*
*checking whether yytext is a pointer... no*
*checking for bison... bison -y*
*checking ieeefp.h usability... no*
*checking ieeefp.h presence... 

Re: [GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or later is required, but this is .

[Andre Mikulec]

Never mind.  I figured it out.

Soon I will write up a summary.

Andre Mikulec
andre_miku...@hotmail.com



From: Andre Mikulec 
Sent: Sunday, October 23, 2016 7:05 PM
To: pgsql-general@postgresql.org
Cc: Tom Lane
Subject: Re: [GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or 
later is required, but this is .


I corrected 'PERL=' to include the executable.
I tried again.

./configure 
PERL=/c/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/bin/perl5.20.3.exe 
--with-perl 
--with-includes=/c/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE:/c/Users/AnonymousUser/Documents/zlib-1.2.8-win32-x86_64/include
 
--with-libraries=/c/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/bin:/c/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE:/c/Users/AnonymousUser/Documents/zlib-1.2.8-win32-x86_64/bin:/c/Users/AnonymousUser/Documents/zlib-1.2.8-win32-x86_64/lib
  --host=x86_64-w64-mingw32 --prefix=/usr/local/pgsql_0ab9c56_debug 
--disable-rpath --enable-depend --enable-cassert --enable-debug 
--with-extra-version=_CFLAGS_O_0ab9c56 CFLAGS="-O -fno-omit-frame-pointer"  
2>&1 | tee configure_OPTIONS_EnterpriseDB_PERL_without_SUBDIR_sys.txt

Relevant output is the following.

checking whether to build Perl modules... yes

configure: using perl 5.20.3
checking for Perl archlibexp... 
C:/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib
checking for Perl privlibexp... 
C:/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib
checking for Perl useshrplib... true
checking for flags to link embedded Perl... 
-LC:/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE -lperl520

checking for perl.h... yes
checking for libperl... yes

configure: using CPPFLAGS= -I./src/include/port/win32 -DEXEC_BACKEND  
-I/c/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE 
-I/c/Users/AnonymousUser/Documents/zlib-1.2.8-win32-x86_64/include

configure: using LDFLAGS= -Wl,--allow-multiple-definition 
-Wl,--disable-auto-import  -L/c/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/bin 
-L/c/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE 
-L/c/Users/AnonymousUser/Documents/zlib-1.2.8-win32-x86_64/bin 
-L/c/Users/AnonymousUser/Documents/zlib-1.2.8-win32-x86_64/lib -Wl,--as-needed

I try to 'make'

make 2>&1 | tee make_ALONE_OPTIONS_EnterpriseDB_PERL_without_SUBDIR_sys.txt

But now within the 'make', I am getting complaints
saying "warning: win32_FUNCTION redefined."

x86_64-w64-mingw32-gcc -Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute 
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g 
-O -fno-omit-frame-pointer  -I../../src/port  -I../../src/include 
-I./src/include/port/win32 -DEXEC_BACKEND  
-I/c/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE 
-I/c/Users/AnonymousUser/Documents/zlib-1.2.8-win32-x86_64/include 
"-I../../src/include/port/win32" -DBUILDING_DLL -c path.c -o path_srv.o
In file included from 
c:/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE/netdb.h:10:0,
 from ../../src/include/port.h:17,
 from ../../src/include/c.h:1105,
 from ../../src/include/postgres.h:47,
 from path.c:17:
c:/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE/sys/socket.h:272:0: 
warning: "socket" redefined
 #define socket  win32_socket

In file included from ../../src/include/c.h:101:0,
 from ../../src/include/postgres.h:47,
 from path.c:17:
../../src/include/pg_config_os.h:379:0: note: this is the location of the 
previous definition
 #define socket(af, type, protocol) pgwin32_socket(af, type, protocol)

In file included from 
c:/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE/netdb.h:10:0,
 from ../../src/include/port.h:17,
 from ../../src/include/c.h:1105,
 from ../../src/include/postgres.h:47,
 from path.c:17:
c:/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE/sys/socket.h:273:0: 
warning: "bind" redefined
 #define bind  win32_bind

These complaints go on and on, but they are all similar.
They seem to be complaints about networking functions begin re-defined

win32_*
E.g. win32_connect

These function headers are found in the python subdirectory and files.

CORE/sys/socket.h
CORE/netdb.h

They were most like likely included by using the

./configure line --with-includes option

--with-includes=/c/EnterpriseDB/LanguagePack/9.5/x64/Perl-5.20/lib/CORE

Note, perl.h lives in lib/CORE, so I am not sure about removing that option.

Eventually, these complaints lead to . . .

x86_64-w64-mingw32-gcc -Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute 
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g 
-O -fno-omit-frame-pointer   -shared -static-libgcc -o libpq.dll  fe-auth.o 
fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o 

Re: [GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or later is required, but this is .

[Andre Mikulec]

Never mind. I figured it out.

Soon, I will write up a summary.

Andre Mikulec
andre_miku...@hotmail.com



From: Adrian Klaver 
Sent: Sunday, October 23, 2016 7:18 PM
To: Andre Mikulec; pgsql-general@postgresql.org
Cc: Tom Lane
Subject: Re: [GENERAL] configure PostgreSQL with PERL: Perl version 5.8 or 
later is required, but this is .

On 10/23/2016 04:05 PM, Andre Mikulec wrote:
>
> I corrected 'PERL=' to include the executable.
> I tried again.
>

Where did you get the Postgres source you are trying to build?




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

Re: [GENERAL] checkpoint write errors ( getting worse )

[CS DBA]

Understood, thanks. This is a new server fired up for our client by 
Rackspace


Not real impressed so far, for the first several days we had major 
performance issues even thought new new HW had more memory and 
more/faster CPU's and faster IO - turned out rackspace had turned on cpu 
throttling limiting the server to no more than 2 cpu's





On 10/23/2016 10:53 PM, Michael Paquier wrote:

On Sun, Oct 23, 2016 at 12:45 PM, CS DBA  wrote:

would a dump/restore correct these issues?

Not directly, but it would give a logical representation of your data,
or a good start image that you could deploy on a server that has less
problems. You seem to be facing advanced issues with your hardware
here.




--
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] Doubts about replication from many servers

[Edilmar LISTAS]

Em 21-10-2016 13:48, Adrian Klaver escreveu:

On 10/21/2016 08:09 AM, Edilmar LISTAS wrote:

Hi,

I have 4 PG servers where each one runs many databases.

Now, I would like to create just one PG backup server to replicate all
the databases from 4 PG servers, is it possible? Or Do I need to create
4 PG backup servers?


More information is needed:

1) Are all 4 PG servers the same version, on the same OS, same chip
architecture?


Right, 4 PG main servers with same version/OS/arch.



2) What replication method do you want to use?



Just to create a backup "big" PG server.
I think the suggestion from Walter Cachique in another message about to 
use one different port for each backup server, and configure 4 backups

may be a good solution.



And if some PG server goes down, how to recovery the system from PG
backup after I reconfigure the PG original server?










--
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] SERIALIZABLE and INSERTs with multiple VALUES

[Kevin Grittner]

On Thu, Oct 13, 2016 at 5:26 PM, Thomas Munro
 wrote:

> (1)  postgres=# create table bank_account (id int primary key, cash int);
> (1)  CREATE TABLE
> (1)  postgres=# begin transaction isolation level serializable ;
> (1)  BEGIN
>
> (2)  postgres=# begin transaction isolation level serializable ;
> (2)  BEGIN
>
> (1)  postgres=# select * from bank_account where id = 1;
> (1)  ┌┬──┐
> (1)  │ id │ cash │
> (1)  ├┼──┤
> (1)  └┴──┘
> (1)  (0 rows)
>
> (2)  postgres=# insert into bank_account values (1, 100);
> (2)  INSERT 0 1
>
> (1)  postgres=# insert into bank_account values (1, 200) on conflict do 
> nothing;
> (1)  ...waits for tx2...
>
> (2)  postgres=# commit;
> (2)  COMMIT
>
> (1)  INSERT 0 0
> (1)  postgres=# commit;
> (1)  COMMIT

This is a really diabolical example.  (Thanks for that!)

Without use of the ON CONFLICT option, using standard statements in
SERIALIZABLE transactions there would be no serialization anomaly.
If both transactions first tested for the existence of the row with
a SELECT statement tx1 would get a serialization failure; in the
example as shown tx1 would get a duplicate key error (even though
we would like to get to the point of having it get a serialization
failure).

If we took out the existing check and modified INSERT under
SERIALIZABLE transactions to acquire predicate locks during initial
insertion of the index key in the index used by the ON CONFLICT
clause (like the ones which would be acquired by a SELECT which
used the index), we would handle many cases, but not this one
(since the INSERT in tx2 does not use the ON CONFLICT clause).
This example would cause a rw-conflict from tx1 to tx2, but not
vice versa, since tx2 doesn't read.  So, no "dangerous structure"
in the SSI sense, and no serialization failure, even though the
results are not consistent with any serial execution of the
transactions.

I *think* that to generate the correct rw-conflicts to allow
dropping the existing check (recently proposed by Thomas Munro and
implemented by Tom Lane), we would need to acquire predicate locks
during the descent to insert into each unique index during any
INSERT under SERIALIZABLE transaction isolation.  The obvious
question is whether the overhead of doing that would be made up by
the work saved through reduced false positive serialization
failures.  It does not seem obvious which would win on overall
performance; in fact it seems very likely that it would depend on
the workload.

My initial thought is that since reducing the false positive rate
would only help when there was a high rate of conflicts under the
existing patch, and it would add code complexity and cost for the
case where conflict rate is low, that we might want to just leave
the current fix and see whether there are complaints from the field
about the false positive rate.

Reducing the rate of false positive serialization failures is a
worthy goal, but it's gotta make sense from a cost/benefit
perspective.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] out-of-order XID insertion in KnownAssignedXids

[Kevin Grittner]

On Mon, Oct 24, 2016 at 8:10 AM,   wrote:

> This was actually introduced some time back, and I am not completely certain
> how it crept into our codebase. I think that at least part of the
> explanation lies in the fact that we are experiencing a fair amount of
> growth in the database size and use on some of our installations. This could
> be the reason why extensive testing did not show the issue back then and why
> we are seeing it now.

If there is no checkpoint during the backup, you dodge the
corruption.  Higher update volume increases the frequency of
checkpoints and larger cluster size makes the backup take longer --
either of which would make corruption more likely.

> Would it make sense to log a warning in the case of a missing backup_label
> file, or would it be difficult to identify that situation in the code?

The problem is, without a backup_label file things look exactly
like a crash recovery, which is why it just goes to the last usable
checkpoint; that's the correct behavior for crash recovery.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
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] out-of-order XID insertion in KnownAssignedXids

[fredrik]

Hi All,

thank you all, I sincerely appreciate your feedback.

I have done a fair amount of testing on the solution proposed by you all (not 
removing backup_label), and it seems to have completely addressed the issue.

This was actually introduced some time back, and I am not completely certain 
how it crept into our codebase. I think that at least part of the explanation 
lies in the fact that we are experiencing a fair amount of growth in the 
database size and use on some of our installations. This could be the reason 
why extensive testing did not show the issue back then and why we are seeing it 
now.

Would it make sense to log a warning in the case of a missing backup_label 
file, or would it be difficult to identify that situation in the code? I would 
be happy to dig in and develop a patch?


With regards to the package version; we *are* working with a few "stock" 
scenarios, where one of them is a fairly old RHEL installation. We also have 
centos versions that are much more updated.
Best regards, and thank you all again,

Fredrik
On 20 October 2016 at 22:38:26 +02:00, Andres Freund  wrote:

> On 2016-10-20 22:37:15 +0900, Michael Paquier wrote:
> 
> > On Thu, Oct 20, 2016 at 10:21 PM, <> wrote:
> > 
> > > - remove a file called backup_label, but I am not certain that this file 
> > > is
> > > in fact there (any more).
> > > 
> > It is never a good idea when you are trying to restore from a backup,
> > backup_label contains critical information when restoring from a
> > backup, so you may finish with a corrupted data folder.
> > 
> And this actually seems like a likely source of these errors. Removing
> a backup label unfortunately causes hard to diagnose errors, because
> everything appears to be ok as long as there's no checkpoints while
> taking the base backups (or when the control file was copied early
> enough). But as soon as a second checkpoint happens before the control
> file is copied...
> 
> Fredrik, how did you end up removing the label?
> 
> Greetings,
>
> Andres Freund
>

Re: [GENERAL] Errors while installing PostGIS by an unusual method

[Tom Lane]

Ankit Sablok  writes:
> I am trying to install PostGIS on a RHEL_5 system and failing at it
> miserably. The way I am trying to install it is as follows. I copy over all
> the artifacts of postgresql server as in the bin, lib, share directories of
> postgresql server in a directory called pgql and I place it in the root
> directory i.e /pgsql is the directory which contains things like pg_config
> and all the other libs and bins that one gets by installing postgresql
> using the standard installation.

(1) did you remember the include directory?

(2) I think this process will not work unless /pgsql was also the install
directory on the source machine.  You can check that by running pg_config
by hand and seeing what it prints for INCLUDEDIR, but it looks to me like
it just parrots what PG's configure expected the installation path to be.

(This is assuming that PostGIS's configure even pays attention to what
pg_config says for INCLUDEDIR.  I've not checked.)

Is there a good reason why you're not building Postgres on the same
machine where you're building PostGIS?  It seems like a recipe for
trouble, with little to be gained.

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] json-patch support?

[Deven Phillips]

Finally got around to doing this... The link below points to a complete
implementation of JSONPatch in pure PostgreSQL. It is compatible with
PostgreSQL >= 9.5 (Not tested using earlier versions)

https://gist.github.com/InfoSec812/b830a9db4c9048552f8c51d7987cc4d0

Cheers!

Deven

On Fri, Mar 27, 2015 at 4:16 PM, Deven Phillips 
wrote:

> OK, then I will look into perhaps implementing it as a pl-python or
> pl-java function. Thanks for the advice!!
>
> Deven
>
> On Fri, Mar 27, 2015 at 2:40 PM, Merlin Moncure 
> wrote:
>
>> On Fri, Mar 27, 2015 at 1:36 PM, Arthur Silva 
>> wrote:
>> > On Fri, Mar 27, 2015 at 1:56 PM, Deven Phillips <
>> deven.phill...@gmail.com>
>> > wrote:
>> >>
>> >> Are there any plans or ideas about implement JSON Patch
>> >> (http://jsonpatch.com/) support for PostgreSQL? We deal with some
>> relatively
>> >> large JSON documents for our in-house application and it is often
>> better to
>> >> just send a json-patch update rather than the full document. It would
>> be
>> >> very nice if we could just select for the changes via a trigger and use
>> >> NOTIFY to tell our application about a patch. If nobody has discussed
>> it
>> >> previously, perhaps I will look into implementing it myself.
>> >>
>> >> Thanks in advance,
>> >>
>> >> Deven
>> >
>> >
>> > This could be implemented as an extension.
>> > There're already a few extensions that provide this functionality with
>> plain
>> > functions, so it's just a matter of parsing the json and executing those
>> > functions.
>>
>>
>> Right.  If it was me, I'd shoot for a userland (that is, in sql or
>> pl/pgsql) implementation that wraps the existing json APIs to get the
>> desired result.   From there, could determine if a more optimized
>> version in C was warranted.
>>
>> merlin
>>
>
>

Re: [GENERAL] postgres_fdw : disable extended queries

[Nicolas Paris]

2016-10-24 10:36 GMT+02:00 Albe Laurenz :

> Nicolas Paris wrote:
> > I have a 9.6 pg instance, and I am trying to link a foreign postgresql
> database that do not accept
> > extended queries. (only simple queries https://www.postgresql.org/
> docs/current/static/protocol.html )
> >
> > When I run a query against the foreign pg instance thought postres_fdw,
> it looks like it sends a
> > transaction containing
> >
> > DECLARE c1 CURSOR FOR
> > SELECT customer_id FROM foodmart.customer
> >
> > -> is there a way to run a simple query with postgres_fdw such:
> >
> > SELECT customer_id FROM foodmart.customer
>
> No, it is part of the design that cursors are used, so that rows can be
> fetched one at a time and concurrent DML statements can be run.
>

​Actually problem is not with the cursor, sorry. Error message says it's
related to a prepared statement.
I am not able to debug it and see what is happening and what is the
prepared statement. ​



> You might consider using dblink.
>
​
Dblink works great, but It seems less flexible (no predicate push down). I
am able to create a view that encapsulate dblink, but all the rows are
fetch each time I use the view.


> Yours,
> Laurenz Albe
>

Re: [GENERAL] postgres_fdw : disable extended queries

[Albe Laurenz]

Nicolas Paris wrote:
> I have a 9.6 pg instance, and I am trying to link a foreign postgresql 
> database that do not accept
> extended queries. (only simple queries 
> https://www.postgresql.org/docs/current/static/protocol.html )
> 
> When I run a query against the foreign pg instance thought postres_fdw, it 
> looks like it sends a
> transaction containing
> 
> DECLARE c1 CURSOR FOR
> SELECT customer_id FROM foodmart.customer
> 
> -> is there a way to run a simple query with postgres_fdw such:
> 
> SELECT customer_id FROM foodmart.customer

No, it is part of the design that cursors are used, so that rows can be
fetched one at a time and concurrent DML statements can be run.

You might consider using dblink.

Yours,
Laurenz Albe

-- 
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] Errors while installing PostGIS by an unusual method

[Asif Naeem]

Hi Ankit,

Can you please share the generated config.log ?

Following works for me i.e.

> export
> PATH=/work/postgresql/inst/bin:/opt/proj-4.7.0/inst/bin:/opt/gdal-1.9.1/inst/bin:/opt/geos-3.3.5/inst/bin:$PATH
>
export
> LD_LIBRARY_PATH=/work/postgresql/inst/lib:/opt/proj-4.7.0/inst/lib:/opt/gdal-1.9.1/inst/lib:/opt/geos-3.3.5/inst/lib:$LD_LIBRARY_PATH

./configure --prefix=$PWD/inst --with-projdir=/opt/proj-4.7.0/inst &>
> configure.log
> make &> make.log


Regards,
Muhammad Asif Naeem

On Mon, Oct 24, 2016 at 11:15 AM, Ankit Sablok  wrote:

> I am trying to install PostGIS on a RHEL_5 system and failing at it
> miserably. The way I am trying to install it is as follows. I copy over all
> the artifacts of postgresql server as in the bin, lib, share directories of
> postgresql server in a directory called pgql and I place it in the root
> directory i.e /pgsql is the directory which contains things like pg_config
> and all the other libs and bins that one gets by installing postgresql
> using the standard installation. All the dependencies of PostGIS get
> installed successfully using the standard build process of *./configure
> --prefix=/pgsql, make and make install* but when I issue the following
> command for building PostGIS using the same process :
>
> ./configure --with-gdalconfig=/pgsql/bin/gdal-config
> --with-geosconfig=/pgsql/bin/geos-config --with-projdir=/pgsql
> --with-jsondir=/pgsql --with-pgconfig=/pgsql/bin/pg_config
>
> I get the following error in the configure step :
>
> checking PostgreSQL version... PostgreSQL 9.6
>
> checking libpq-fe.h usability... no
>
> checking libpq-fe.h presence... no
>
> checking for libpq-fe.h... no
>
> configure: error: could not find libpq-fe.h"
>
> to remedy this error I tried placing the include files in the include
> directory of postgresql by find the appropriate path using
>
> /pgsql/bin/pg_config --includedir
>
> and then when I try to install PostGIS, it still fails. Can anyone suggest
> some workaround to build PostGIS using this non-standard approach of
> building PostGIS?
>
> Edit: When I try to add all the include files which includes the
> libpq-fe.h and libpq headers as well along with other header I get the
> following error when configuring PostGIS
>
> checking for PQserverVersion in -lpq... no
>
> configure: error: could not find libpq
>
>
>
>

[GENERAL] Errors while installing PostGIS by an unusual method

[Ankit Sablok]

I am trying to install PostGIS on a RHEL_5 system and failing at it
miserably. The way I am trying to install it is as follows. I copy over all
the artifacts of postgresql server as in the bin, lib, share directories of
postgresql server in a directory called pgql and I place it in the root
directory i.e /pgsql is the directory which contains things like pg_config
and all the other libs and bins that one gets by installing postgresql
using the standard installation. All the dependencies of PostGIS get
installed successfully using the standard build process of *./configure
--prefix=/pgsql, make and make install* but when I issue the following
command for building PostGIS using the same process :

./configure --with-gdalconfig=/pgsql/bin/gdal-config
--with-geosconfig=/pgsql/bin/geos-config --with-projdir=/pgsql
--with-jsondir=/pgsql --with-pgconfig=/pgsql/bin/pg_config

I get the following error in the configure step :

checking PostgreSQL version... PostgreSQL 9.6

checking libpq-fe.h usability... no

checking libpq-fe.h presence... no

checking for libpq-fe.h... no

configure: error: could not find libpq-fe.h"

to remedy this error I tried placing the include files in the include
directory of postgresql by find the appropriate path using

/pgsql/bin/pg_config --includedir

and then when I try to install PostGIS, it still fails. Can anyone suggest
some workaround to build PostGIS using this non-standard approach of
building PostGIS?

Edit: When I try to add all the include files which includes the libpq-fe.h
and libpq headers as well along with other header I get the following error
when configuring PostGIS

checking for PQserverVersion in -lpq... no

configure: error: could not find libpq