Re: [GENERAL] Replication rolling back to normal.

2016-10-23 Thread Michael Paquier 
On Mon, Oct 24, 2016 at 2:20 PM, Dasitha Karunajeewa
 wrote:
> Hi Michael,
>
> Thanks a lot for the information. I am totally new to Postgres clustering. I
> have follow up the below-attached article.
> https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-on-postgresql-on-an-ubuntu-12-04-vps
>
> Can u guide me on how to do it as u mentioned :)

Documentation is your best friend:
https://www.postgresql.org/docs/9.6/static/high-availability.html
-- 
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] checkpoint write errors ( getting worse )

2016-10-23 Thread Michael Paquier 
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.
-- 
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] SERIALIZABLE and INSERTs with multiple VALUES

2016-10-23 Thread Tom Lane 
I've pushed a simplified (no refactoring) version of the fix proposed
by Thomas and Peter, so that we have some kind of fix in place for
tomorrow's releases.  I think further improvement along the lines
suggested by Kevin can wait till later.

I noticed that the ON CONFLICT DO NOTHING and ON CONFLICT DO UPDATE cases
are now not terribly consistent about what to do with self-conflicting
insertions.  The examples memorialized in commit a6c0a5b6e are

insert into selfconflict values (1,1), (1,2) on conflict do nothing;
-- succeeds, inserting the first row and ignoring the second

insert into selfconflict values (4,1), (4,2) on conflict(f1) do update set f2 = 
0;
ERROR:  ON CONFLICT DO UPDATE command cannot affect row a second time
HINT:  Ensure that no rows proposed for insertion within the same command have 
duplicate constrained values.

I think that if we believe the first behavior is correct, then the second
behavior is a bug; what that command should do is to insert a single row
containing (4,0).  However, that behavior is the same across all isolation
levels, and it was like that before today's patches, so I didn't undertake
to do anything about it right now.

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

2016-10-23 Thread Adrian Klaver 

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


--
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 .

2016-10-23 Thread Andre Mikulec 

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 fe-protocol2.o 
fe-protocol3.o pqexpbuffer.o fe-secure.o libpq-events.o chklocale.o 
inet_net_ntop.o noblock.o pgstrcasecmp.o pqsignal.o thread.o crypt.o 
inet_aton.o strlcpy.o getaddrinfo.o open.o system.o win32error.o 
win32setlocale.o snprintf.o encnames.o wchar.o ip.o md5.o pgsleep.o win32.o 
libpqrc.o pthread-win32.o libpqdll.def -L../../../src/port 
-L../../../src/common

Re: [GENERAL] Exclude pg_largeobject form pg_dump

2016-10-23 Thread Andreas Joseph Krogh 
På søndag 23. oktober 2016 kl. 20:44:34, skrev Guillaume Lelarge <
guilla...@lelarge.info >:
[snip]
Remember that, if it gets commited, it'll be for next release (aka 10), and 
not 9.6 and earlier.



 
The patch working for 9.6 is fine for me, but getting this in master is of 
course the best.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

Re: [GENERAL] Exclude pg_largeobject form pg_dump

2016-10-23 Thread Guillaume Lelarge 
2016-10-23 20:44 GMT+02:00 Guillaume Lelarge :

> 2016-10-23 20:37 GMT+02:00 Andreas Joseph Krogh :
>
>> På søndag 23. oktober 2016 kl. 19:15:17, skrev Andreas Joseph Krogh <
>> andr...@visena.com>:
>>
>> På søndag 23. oktober 2016 kl. 17:06:57, skrev Guillaume Lelarge <
>> guilla...@lelarge.info>:
>>
>> 2016-03-08 21:06 GMT+01:00 Andreas Joseph Krogh :
>>>
>>> På tirsdag 08. mars 2016 kl. 21:03:01, skrev David G. Johnston <
>>> david.g.johns...@gmail.com>:
>>>
>>> On Tue, Mar 8, 2016 at 9:45 AM, Andreas Joseph Krogh >> > wrote:
>>>
 På tirsdag 08. mars 2016 kl. 17:38:04, skrev Joshua D. Drake <
 j...@commandprompt.com>:

 On 03/08/2016 08:02 AM, Andreas Joseph Krogh wrote:
 > På tirsdag 08. mars 2016 kl. 16:57:01, skrev Tom Lane <
 t...@sss.pgh.pa.us
 > >:
 >
 > Andreas Joseph Krogh  writes:
 >  > What I'm looking for is "inverse -b" in an otherwise complete
 > dump. Any plans
 >  > to add that?
 >
 > [ shrug... ]  Nobody ever asked for it before.
 >
 > regards, tom lane
 >
 > It surely helps testing production-datasets which contain lots of
 BLOBs
 > where one wants to dump the production-data into a test-env. We have
 >  >1TB databases containing > 95% blobs so it would help us
 tremendously
 > to have this option.

 I have quite a few customers that would benefit from the ability to not
 have blobs present in dumps.


 Great! So how do we proceed to get "--no-blobs" added to pg_dump?
 Maybe CommandPrompt and Visena should co-fund development of such an
 addition, if it's accepted by -hackers?
 We'd be willing to pay for such an addition for the 9.5 branch, as a
 patch.

>>>
>>> ​Unfortunately this doesn't qualify as a bug fix - it is a new feature
>>> and thus is ineligible for inclusion in official 9.5
>>>
>>> David J.
>>>
>>>
>>> Of course. That's why I mentioned that, if possible, an unofficial patch
>>> to 9.5 could be developed, funded partly by Visena (my company). Given that
>>> someone is willing to do this of course.
>>>
>>>
>>
>> That probably should look like the patch attached. It applies cleanly on
>> HEAD, and works AFAICT. If this patch seems interesting enough, I'll add it
>> to the next commit fest (note for myself, update the ref/pg_dump.sgml
>> documentation file).
>>
>> For Andreas' information, it also applies on 9.5, though I didn't check
>> if it worked afterwards.
>>
>>
>> +1 for adding it to the commitfest.
>>
>>
>>
> Done, https://commitfest.postgresql.org/11/833/
>
> It's almost scary how simple this patch is and noone ever got around to
>> implement it.
>>
>>
> Nobody had the time (like me, till now) or the motivation.
>
>
>>
>> Thanks, I'll test it on 9.5 soon.
>>
>>
>> It's totally OK for me to use 9.6 (now that it's released) to dump 9.5
>> DBs, so I'm all good with this patch, thanks!
>>
>
> Remember that, if it gets commited, it'll be for next release (aka 10),
> and not 9.6 and earlier.
>
>
New patch, this time with the documentation.


-- 
Guillaume.
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 371a614..83dc52f 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -145,6 +145,16 @@ PostgreSQL documentation
  
 
  
+  -B
+  --no-blobs
+  
+   
+Exclude large objects in the dump.
+   
+  
+ 
+
+ 
   -c
   --clean
   
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 4da297f..dd93789 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -379,7 +379,7 @@ main(int argc, char **argv)
 
 	InitDumpOptions();
 
-	while ((c = getopt_long(argc, argv, "abcCd:E:f:F:h:j:n:N:oOp:RsS:t:T:U:vwWxZ:",
+	while ((c = getopt_long(argc, argv, "abBcCd:E:f:F:h:j:n:N:oOp:RsS:t:T:U:vwWxZ:",
 			long_options, )) != -1)
 	{
 		switch (c)
@@ -392,6 +392,10 @@ main(int argc, char **argv)
 dopt.outputBlobs = true;
 break;
 
+			case 'B':			/* Don't dump blobs */
+dopt.include_everything = false;
+break;
+
 			case 'c':			/* clean (i.e., drop) schema prior to create */
 dopt.outputClean = 1;
 break;
@@ -864,6 +868,7 @@ help(const char *progname)
 	printf(_("\nOptions controlling the output content:\n"));
 	printf(_("  -a, --data-only  dump only the data, not the schema\n"));
 	printf(_("  -b, --blobs  include large objects in dump\n"));
+	printf(_("  -B, --no-blobs   exclude large objects in dump\n"));
 	printf(_("  -c, --clean  clean (drop) database objects before recreating\n"));
 	printf(_("  -C, --create include commands to create database in dump\n"));
 	printf(_("  -E,

Re: [GENERAL] Exclude pg_largeobject form pg_dump

2016-10-23 Thread Guillaume Lelarge 
2016-10-23 20:37 GMT+02:00 Andreas Joseph Krogh :

> På søndag 23. oktober 2016 kl. 19:15:17, skrev Andreas Joseph Krogh <
> andr...@visena.com>:
>
> På søndag 23. oktober 2016 kl. 17:06:57, skrev Guillaume Lelarge <
> guilla...@lelarge.info>:
>
> 2016-03-08 21:06 GMT+01:00 Andreas Joseph Krogh :
>>
>> På tirsdag 08. mars 2016 kl. 21:03:01, skrev David G. Johnston <
>> david.g.johns...@gmail.com>:
>>
>> On Tue, Mar 8, 2016 at 9:45 AM, Andreas Joseph Krogh 
>> wrote:
>>
>>> På tirsdag 08. mars 2016 kl. 17:38:04, skrev Joshua D. Drake <
>>> j...@commandprompt.com>:
>>>
>>> On 03/08/2016 08:02 AM, Andreas Joseph Krogh wrote:
>>> > På tirsdag 08. mars 2016 kl. 16:57:01, skrev Tom Lane <
>>> t...@sss.pgh.pa.us
>>> > >:
>>> >
>>> > Andreas Joseph Krogh  writes:
>>> >  > What I'm looking for is "inverse -b" in an otherwise complete
>>> > dump. Any plans
>>> >  > to add that?
>>> >
>>> > [ shrug... ]  Nobody ever asked for it before.
>>> >
>>> > regards, tom lane
>>> >
>>> > It surely helps testing production-datasets which contain lots of BLOBs
>>> > where one wants to dump the production-data into a test-env. We have
>>> >  >1TB databases containing > 95% blobs so it would help us tremendously
>>> > to have this option.
>>>
>>> I have quite a few customers that would benefit from the ability to not
>>> have blobs present in dumps.
>>>
>>>
>>> Great! So how do we proceed to get "--no-blobs" added to pg_dump?
>>> Maybe CommandPrompt and Visena should co-fund development of such an
>>> addition, if it's accepted by -hackers?
>>> We'd be willing to pay for such an addition for the 9.5 branch, as a
>>> patch.
>>>
>>
>> ​Unfortunately this doesn't qualify as a bug fix - it is a new feature
>> and thus is ineligible for inclusion in official 9.5
>>
>> David J.
>>
>>
>> Of course. That's why I mentioned that, if possible, an unofficial patch
>> to 9.5 could be developed, funded partly by Visena (my company). Given that
>> someone is willing to do this of course.
>>
>>
>
> That probably should look like the patch attached. It applies cleanly on
> HEAD, and works AFAICT. If this patch seems interesting enough, I'll add it
> to the next commit fest (note for myself, update the ref/pg_dump.sgml
> documentation file).
>
> For Andreas' information, it also applies on 9.5, though I didn't check if
> it worked afterwards.
>
>
> +1 for adding it to the commitfest.
>
>
>
Done, https://commitfest.postgresql.org/11/833/

It's almost scary how simple this patch is and noone ever got around to
> implement it.
>
>
Nobody had the time (like me, till now) or the motivation.


>
> Thanks, I'll test it on 9.5 soon.
>
>
> It's totally OK for me to use 9.6 (now that it's released) to dump 9.5
> DBs, so I'm all good with this patch, thanks!
>

Remember that, if it gets commited, it'll be for next release (aka 10), and
not 9.6 and earlier.


-- 
Guillaume.
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com

Re: [GENERAL] Exclude pg_largeobject form pg_dump

2016-10-23 Thread Andreas Joseph Krogh 
På søndag 23. oktober 2016 kl. 19:15:17, skrev Andreas Joseph Krogh <
andr...@visena.com >:
På søndag 23. oktober 2016 kl. 17:06:57, skrev Guillaume Lelarge <
guilla...@lelarge.info >:
2016-03-08 21:06 GMT+01:00 Andreas Joseph Krogh >: På tirsdag 08. mars 2016 kl. 21:03:01, skrev 
David G. Johnston >:
On Tue, Mar 8, 2016 at 9:45 AM, Andreas Joseph Krogh > wrote:
På tirsdag 08. mars 2016 kl. 17:38:04, skrev Joshua D. Drake <
j...@commandprompt.com >:
On 03/08/2016 08:02 AM, Andreas Joseph Krogh wrote:
 > På tirsdag 08. mars 2016 kl. 16:57:01, skrev Tom Lane 
 > >>:
 >
 >     Andreas Joseph Krogh > 
writes:
 >      > What I'm looking for is "inverse -b" in an otherwise complete
 >     dump. Any plans
 >      > to add that?
 >
 >     [ shrug... ]  Nobody ever asked for it before.
 >
 >     regards, tom lane
 >
 > It surely helps testing production-datasets which contain lots of BLOBs
 > where one wants to dump the production-data into a test-env. We have
 >  >1TB databases containing > 95% blobs so it would help us tremendously
 > to have this option.

 I have quite a few customers that would benefit from the ability to not
 have blobs present in dumps.
 
Great! So how do we proceed to get "--no-blobs" added to pg_dump?
Maybe CommandPrompt and Visena should co-fund development of such an addition, 
if it's accepted by -hackers?
We'd be willing to pay for such an addition for the 9.5 branch, as a patch.
 
​Unfortunately this doesn't qualify as a bug fix - it is a new feature and 
thus is ineligible for inclusion in official 9.5

 

David J.




 


Of course. That's why I mentioned that, if possible, an unofficial patch to 
9.5 could be developed, funded partly by Visena (my company). Given that 
someone is willing to do this of course.
 


 
That probably should look like the patch attached. It applies cleanly on HEAD, 
and works AFAICT. If this patch seems interesting enough, I'll add it to the 
next commit fest (note for myself, update the ref/pg_dump.sgml documentation 
file).

 For Andreas' information, it also applies on 9.5, though I didn't check if it 
worked afterwards.



 
+1 for adding it to the commitfest.
 
It's almost scary how simple this patch is and noone ever got around to 
implement it.
 
Thanks, I'll test it on 9.5 soon.
 
It's totally OK for me to use 9.6 (now that it's released) to dump 9.5 DBs, so 
I'm all good with this patch, thanks!
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

Re: [GENERAL] make PostgreSQL with TCLSH: No rule to make target

2016-10-23 Thread Andre Mikulec 

Tom,

Along with TCHSH that should reference the tclsh executable and should be 
TCLSH=/c/Tcl.8.5.18.0/bin/tclsh85.exe, the problem ended up being that the 
EnterpriseDB LanguagePack file
C:\EnterpriseDB\LanguagePack\9.5\x64\Tcl-8.5\lib\tclConfig.sh

has the has the hard-coded written line ...

TCL_LIB_SPEC = C:\EnterpriseDB\LanguagePack\9.5\x64\Tcl-8.5\lib\tcl85.lib

Looking at the results of

make -n -C tcl all 2>&1 | tee ../../make_n_C_tcl_all_ALONE.txt

I see

TCL_LIB_SPEC = C:\EnterpriseDB\LanguagePack\9.5\x64\Tcl-8.5\lib\tcl85.lib
tclwithver = $(subst -l,,$(filter -l%, $(TCL_LIB_SPEC)))
dlltool --dllname $(tclwithver).dll --def $(tclwithver).def --output-lib 
lib$(tclwithver).a

So the case seems that the
tclwithver value actually should be 'tcl85'.

ActiveTcl 8.5.18.0 has it different.
The file C:\Tcl.8.5.18.0\lib\tclConfig.sh has the line

TCL_LIB_SPEC='-LC:/Tcl.8.5.18.0/lib -ltcl85'

So maybe ( as you said ), tcl85 is extracted from '-ltcl85'?

Also, the ENTIRE ActiveTcl 8.5.18.0 tclConfig.sh file looks
*radically* different than the EnterpriseDB LanguagePack tclConfig.sh file.

So, I just installed
ActiveTcl8.5.18.0.298892-win32-x86_64-threaded.exe ( ActiveTcl 8.5.18.0 
(64-bit) )
to C:\Tcl.8.5.18.0

Using x86_64-5.3.0-release-posix-seh-rt_v4-rev0 and MinGW and msys on Windows 
7, I then put pexports.exe in the path ( from the 'PostgeSQL happy' Stawberry 
PERL ) in
C:\MinGW\msys\1.0\msys.bat

REM DBD::Pg  --  the DBI PostgreSQL interface for Perl
set  
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Strawberry\c\bin

Then I did

# ActiveTcl 8.5.18.0 )
./configure TCLSH=/c/Tcl.8.5.18.0/bin/tclsh85.exe --with-tcl 
--with-tclconfig=/c/Tcl.8.5.18.0/lib 
--with-includes=/c/Tcl.8.5.18.0/include:/c/Users/TargetUser/Documents/zlib-1.2.8-win32-x86_64/include
 
--with-libraries=/c/Tcl.8.5.18.0/bin:/c/Tcl.8.5.18.0/lib:/c/Users/TargetUser/Documents/zlib-1.2.8-win32-x86_64/bin:/c/Users/TargetUser/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_Tcl.8.5.18.0.txt

make 2>&1 | tee make_ALONE_Tcl.8.5.18.0.txt

make install 2>&1 | tee make_install_Tcl.8.5.18.0.txt

create language pltcl;

Then I followed
http://get.enterprisedb.com/docs/README-languagepack-950.txt
AND
https://www.postgresql.org/docs/9.5/static/pltcl-functions.html

CREATE FUNCTION tcl_max(integer, integer) RETURNS integer AS $$
if {$1 > $2} {return $1}
return $2
$$ LANGUAGE pltcl STRICT;

select tcl_max(5,3);

postgres=# select tcl_max(5,3);
 tcl_max
-
   5
(1 row)

Thanks,
Andre Mikulec
andre_miku...@hotmail.com




From: Tom Lane 
Sent: Thursday, October 20, 2016 10:18 AM
To: Andre Mikulec
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] make PostgreSQL with TCLSH: No rule to make target

Andre Mikulec  writes:
> I am trying to configure PostgreSQL with the pltcl language available.

You're not having any luck with PLs at all, are you?

> $ ./configure TCLSH=/c/EnterpriseDB/LanguagePack/9.5/x64/Tcl-8.5/bin

I seriously doubt that that's a correct value for TCLSH; the variable is
supposed to reference the tclsh executable, not a directory.

> At the very end of the make, I am getting the error message.

> make[3]: *** No rule to make target 
> `/c/EnterpriseDB/LanguagePack/9.5/x64/Tcl-8.5//.dll', needed by `.def'.  Stop.

Comparing that to relevant entries in pl/tcl/Makefile,

tclwithver = $(subst -l,,$(filter -l%, $(TCL_LIB_SPEC)))
TCLDLL = $(dir $(TCLSH))/$(tclwithver).dll

$(tclwithver).def: $(TCLDLL)
pexports $^ > $@

it seems pretty clear that tclwithver is being set to the empty string,
which suggests that TCL_LIB_SPEC is empty or doesn't contain any word
starting with "-l".  You could look into src/Makefile.global to see
what value configure has obtained for TCL_LIB_SPEC.  AFAICT, it gets
that value verbatim from tclConfig.sh, so this suggests something
messed-up about your Tcl installation.  Or maybe the bad value for
TCLSH is somehow causing this, though I'm not sure how.

regards, tom lane

Re: [GENERAL] Exclude pg_largeobject form pg_dump

2016-10-23 Thread Andreas Joseph Krogh 
På søndag 23. oktober 2016 kl. 17:06:57, skrev Guillaume Lelarge <
guilla...@lelarge.info >:
2016-03-08 21:06 GMT+01:00 Andreas Joseph Krogh >: På tirsdag 08. mars 2016 kl. 21:03:01, skrev 
David G. Johnston >:
On Tue, Mar 8, 2016 at 9:45 AM, Andreas Joseph Krogh > wrote:
På tirsdag 08. mars 2016 kl. 17:38:04, skrev Joshua D. Drake <
j...@commandprompt.com >:
On 03/08/2016 08:02 AM, Andreas Joseph Krogh wrote:
 > På tirsdag 08. mars 2016 kl. 16:57:01, skrev Tom Lane 
 > >>:
 >
 >     Andreas Joseph Krogh > 
writes:
 >      > What I'm looking for is "inverse -b" in an otherwise complete
 >     dump. Any plans
 >      > to add that?
 >
 >     [ shrug... ]  Nobody ever asked for it before.
 >
 >     regards, tom lane
 >
 > It surely helps testing production-datasets which contain lots of BLOBs
 > where one wants to dump the production-data into a test-env. We have
 >  >1TB databases containing > 95% blobs so it would help us tremendously
 > to have this option.

 I have quite a few customers that would benefit from the ability to not
 have blobs present in dumps.
 
Great! So how do we proceed to get "--no-blobs" added to pg_dump?
Maybe CommandPrompt and Visena should co-fund development of such an addition, 
if it's accepted by -hackers?
We'd be willing to pay for such an addition for the 9.5 branch, as a patch.
 
​Unfortunately this doesn't qualify as a bug fix - it is a new feature and 
thus is ineligible for inclusion in official 9.5

 

David J.




 


Of course. That's why I mentioned that, if possible, an unofficial patch to 
9.5 could be developed, funded partly by Visena (my company). Given that 
someone is willing to do this of course.
 


 
That probably should look like the patch attached. It applies cleanly on HEAD, 
and works AFAICT. If this patch seems interesting enough, I'll add it to the 
next commit fest (note for myself, update the ref/pg_dump.sgml documentation 
file).

 For Andreas' information, it also applies on 9.5, though I didn't check if it 
worked afterwards.



 
+1 for adding it to the commitfest.
 
It's almost scary how simple this patch is and noone ever got around to 
implement it.
 
Thanks, I'll test it on 9.5 soon.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

[GENERAL] postgres_fdw : disable extended queries

2016-10-23 Thread Nicolas Paris 
Hello,

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

Thanks,

Re: [GENERAL] Exclude pg_largeobject form pg_dump

2016-10-23 Thread Guillaume Lelarge 
2016-03-08 21:06 GMT+01:00 Andreas Joseph Krogh :

> På tirsdag 08. mars 2016 kl. 21:03:01, skrev David G. Johnston <
> david.g.johns...@gmail.com>:
>
> On Tue, Mar 8, 2016 at 9:45 AM, Andreas Joseph Krogh 
> wrote:
>
>> På tirsdag 08. mars 2016 kl. 17:38:04, skrev Joshua D. Drake <
>> j...@commandprompt.com>:
>>
>> On 03/08/2016 08:02 AM, Andreas Joseph Krogh wrote:
>> > På tirsdag 08. mars 2016 kl. 16:57:01, skrev Tom Lane <
>> t...@sss.pgh.pa.us
>> > >:
>> >
>> > Andreas Joseph Krogh  writes:
>> >  > What I'm looking for is "inverse -b" in an otherwise complete
>> > dump. Any plans
>> >  > to add that?
>> >
>> > [ shrug... ]  Nobody ever asked for it before.
>> >
>> > regards, tom lane
>> >
>> > It surely helps testing production-datasets which contain lots of BLOBs
>> > where one wants to dump the production-data into a test-env. We have
>> >  >1TB databases containing > 95% blobs so it would help us tremendously
>> > to have this option.
>>
>> I have quite a few customers that would benefit from the ability to not
>> have blobs present in dumps.
>>
>>
>> Great! So how do we proceed to get "--no-blobs" added to pg_dump?
>> Maybe CommandPrompt and Visena should co-fund development of such an
>> addition, if it's accepted by -hackers?
>> We'd be willing to pay for such an addition for the 9.5 branch, as a
>> patch.
>>
>
> ​Unfortunately this doesn't qualify as a bug fix - it is a new feature and
> thus is ineligible for inclusion in official 9.5
>
> David J.
>
>
> Of course. That's why I mentioned that, if possible, an unofficial patch
> to 9.5 could be developed, funded partly by Visena (my company). Given that
> someone is willing to do this of course.
>
>

That probably should look like the patch attached. It applies cleanly on
HEAD, and works AFAICT. If this patch seems interesting enough, I'll add it
to the next commit fest (note for myself, update the ref/pg_dump.sgml
documentation file).

For Andreas' information, it also applies on 9.5, though I didn't check if
it worked afterwards.


-- 
Guillaume.
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 4da297f..dd93789 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -379,7 +379,7 @@ main(int argc, char **argv)
 
 	InitDumpOptions();
 
-	while ((c = getopt_long(argc, argv, "abcCd:E:f:F:h:j:n:N:oOp:RsS:t:T:U:vwWxZ:",
+	while ((c = getopt_long(argc, argv, "abBcCd:E:f:F:h:j:n:N:oOp:RsS:t:T:U:vwWxZ:",
 			long_options, )) != -1)
 	{
 		switch (c)
@@ -392,6 +392,10 @@ main(int argc, char **argv)
 dopt.outputBlobs = true;
 break;
 
+			case 'B':			/* Don't dump blobs */
+dopt.include_everything = false;
+break;
+
 			case 'c':			/* clean (i.e., drop) schema prior to create */
 dopt.outputClean = 1;
 break;
@@ -864,6 +868,7 @@ help(const char *progname)
 	printf(_("\nOptions controlling the output content:\n"));
 	printf(_("  -a, --data-only  dump only the data, not the schema\n"));
 	printf(_("  -b, --blobs  include large objects in dump\n"));
+	printf(_("  -B, --no-blobs   exclude large objects in dump\n"));
 	printf(_("  -c, --clean  clean (drop) database objects before recreating\n"));
 	printf(_("  -C, --create include commands to create database in dump\n"));
 	printf(_("  -E, --encoding=ENCODING  dump the data in encoding ENCODING\n"));

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