Postgresql for cygwin - 3rd
Il 3/6/2013 11:46 PM, Andrew Dunstan ha scritto:
Excellent. Will test it out soon.
cheers
andrew
Andrew,
please find attached a full patch for cygwin relative to 9.3beta1 :
- DLLTOLL/DLLWRAP are not used anymore, replaced
by gcc also for postgres.exe (*)
- DLL versioning is added
Check failures:
- prepared_xacts is still freezing
The cygwin failure you highlighted was solved,
so it should be something else
- attached the 2 regressions diffs
tsearch ... FAILED
without_oid ... FAILED
The second one seems a new one, not sure cygwin specific
Regards
Marco
Attachments:
postgresql-9.3beta1-cygwin.patchtext/plain; charset=windows-1252; name=postgresql-9.3beta1-cygwin.patchDownload
--- origsrc/postgresql-9.3beta1/src/Makefile.global.in 2013-05-06 22:57:06.000000000 +0200
+++ src/postgresql-9.3beta1/src/Makefile.global.in 2013-06-08 15:33:28.587266200 +0200
@@ -508,6 +508,11 @@ ifeq ($(PORTNAME),win32)
LIBS += -lws2_32 -lshfolder
endif
+# missing for link on cygwin ?
+ifeq ($(PORTNAME),cygwin)
+LIBS += $(LDAP_LIBS_BE)
+endif
+
# Not really standard libc functions, used by the backend.
TAS = @TAS@
--- origsrc/postgresql-9.3beta1/src/Makefile.shlib 2013-05-06 22:57:06.000000000 +0200
+++ src/postgresql-9.3beta1/src/Makefile.shlib 2013-06-08 15:33:28.613267700 +0200
@@ -281,8 +281,9 @@ ifeq ($(PORTNAME), unixware)
endif
ifeq ($(PORTNAME), cygwin)
+ LINK.shared = $(CC) -shared
ifdef SO_MAJOR_VERSION
- shlib = cyg$(NAME)$(DLSUFFIX)
+ shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX)
endif
haslibarule = yes
endif
@@ -371,6 +372,12 @@ else # PORTNAME == cygwin || PORTNAME ==
# If SHLIB_EXPORTS is set, the rules below will build a .def file from
# that. Else we build a temporary one here.
+ifeq ($(PORTNAME), cygwin)
+$(shlib) $(stlib): $(OBJS) | $(SHLIB_PREREQS)
+ $(CC) $(CFLAGS) -shared -o $(shlib) -Wl,--out-implib=$(stlib) $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) $(LDAP_LIBS_BE)
+
+
+else
ifeq (,$(SHLIB_EXPORTS))
DLL_DEFFILE = lib$(NAME)dll.def
exports_file = $(DLL_DEFFILE)
@@ -387,6 +394,7 @@ $(shlib): $(OBJS) $(DLL_DEFFILE) | $(SHL
$(stlib): $(shlib) $(DLL_DEFFILE) | $(SHLIB_PREREQS)
$(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(DLL_DEFFILE) --output-lib $@
+endif # PORTNAME == cygwin
endif # PORTNAME == cygwin || PORTNAME == win32
--- origsrc/postgresql-9.3beta1/src/backend/Makefile 2013-05-06 22:57:06.000000000 +0200
+++ src/postgresql-9.3beta1/src/backend/Makefile 2013-06-08 15:33:28.633268800 +0200
@@ -62,18 +62,8 @@ endif
ifeq ($(PORTNAME), cygwin)
-postgres: $(OBJS) postgres.def libpostgres.a
- $(DLLTOOL) --dllname $@$(X) --output-exp $@.exp --def postgres.def
- $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -o $@$(X) -Wl,--base-file,$@.base $@.exp $(call expand_subsys,$(OBJS)) $(LIBS)
- $(DLLTOOL) --dllname $@$(X) --base-file $@.base --output-exp $@.exp --def postgres.def
- $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -Wl,--stack,$(WIN32_STACK_RLIMIT) -o $@$(X) $@.exp $(call expand_subsys,$(OBJS)) $(LIBS)
- rm -f $@.exp $@.base
-
-postgres.def: $(OBJS)
- $(DLLTOOL) --export-all --output-def $@ $(call expand_subsys,$^)
-
-libpostgres.a: postgres.def
- $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@
+postgres libpostgres.a: $(OBJS)
+ $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) $(export_dynamic) $(call expand_subsys,$^) $(LIBS) -o $@ -Wl,--stack,$(WIN32_STACK_RLIMIT) -Wl,--export-all-symbols -Wl,--out-implib=libpostgres.a
endif # cygwin
--- origsrc/postgresql-9.3beta1/src/interfaces/libpq/Makefile 2013-05-06 22:57:06.000000000 +0200
+++ src/postgresql-9.3beta1/src/interfaces/libpq/Makefile 2013-06-08 15:33:28.654270000 +0200
@@ -45,7 +45,7 @@ OBJS += ip.o md5.o
OBJS += encnames.o wchar.o
ifeq ($(PORTNAME), cygwin)
-override shlib = cyg$(NAME)$(DLSUFFIX)
+override shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX)
endif
ifeq ($(PORTNAME), win32)
--- origsrc/postgresql-9.3beta1/src/makefiles/Makefile.cygwin 2013-05-06 22:57:06.000000000 +0200
+++ src/postgresql-9.3beta1/src/makefiles/Makefile.cygwin 2013-06-08 16:03:24.065961700 +0200
@@ -1,6 +1,4 @@
# src/makefiles/Makefile.cygwin
-DLLTOOL= dlltool
-DLLWRAP= dllwrap
ifdef PGXS
BE_DLLLIBS= -L$(libdir) -lpostgres
else
@@ -44,6 +42,4 @@ endif
# Rule for building a shared library from a single .o file
%.dll: %.o
- $(DLLTOOL) --export-all --output-def $*.def $<
- $(DLLWRAP) -o $@ --def $*.def $< $(LDFLAGS) $(LDFLAGS_SL) $(BE_DLLLIBS)
- rm -f $*.def
+ $(CC) $(CFLAGS) -shared -o $@ $< $(LDFLAGS) $(LDFLAGS_SL) $(BE_DLLLIBS)
regression.diffstext/plain; charset=windows-1252; name=regression.diffsDownload
*** /pub/devel/postgresql/postgresql-9.3beta1-1/src/postgresql-9.3beta1/src/test/regress/expected/tsearch.out 2013-05-06 22:57:06.000000000 +0200
--- /pub/devel/postgresql/postgresql-9.3beta1-1/build/src/test/regress/results/tsearch.out 2013-06-10 10:22:21.369652800 +0200
***************
*** 267,276 ****
SELECT * FROM ts_parse('default', '345 qwe@efd.r '' http://www.com/ http://aew.werc.ewr/?ad=qwe&dw 1aew.werc.ewr/?ad=qwe&dw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwe&dw http://4aew.werc.ewr http://5aew.werc.ewr:8100/? ad=qwe&dw 6aew.werc.ewr:8100/?ad=qwe&dw 7aew.werc.ewr:8100/?ad=qwe&dw=%20%32 +4.0e-10 qwe qwe qwqwe 234.435 455 5.005 teodor@stack.net qwe-wer asdf <fr>qwer jf sdjk<we hjwer <werrwe> ewr1> ewri2 <a href="qwe<qwe>">
/usr/local/fff /awdf/dwqe/4325 rewt/ewr wefjn /wqe-324/ewr gist.h gist.h.c gist.c. readline 4.2 4.2. 4.2, readline-4.2 readline-4.2. 234
<i <b> wow < jqw <> qwerty');
! tokid | token
! -------+--------------------------------------
! 22 | 345
! 12 |
1 | qwe
12 | @
19 | efd.r
--- 267,277 ----
SELECT * FROM ts_parse('default', '345 qwe@efd.r '' http://www.com/ http://aew.werc.ewr/?ad=qwe&dw 1aew.werc.ewr/?ad=qwe&dw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwe&dw http://4aew.werc.ewr http://5aew.werc.ewr:8100/? ad=qwe&dw 6aew.werc.ewr:8100/?ad=qwe&dw 7aew.werc.ewr:8100/?ad=qwe&dw=%20%32 +4.0e-10 qwe qwe qwqwe 234.435 455 5.005 teodor@stack.net qwe-wer asdf <fr>qwer jf sdjk<we hjwer <werrwe> ewr1> ewri2 <a href="qwe<qwe>">
/usr/local/fff /awdf/dwqe/4325 rewt/ewr wefjn /wqe-324/ewr gist.h gist.h.c gist.c. readline 4.2 4.2. 4.2, readline-4.2 readline-4.2. 234
<i <b> wow < jqw <> qwerty');
! tokid | token
! -------+-------------------------
! 12 | 3
! 12 | 4
! 12 | 5
1 | qwe
12 | @
19 | efd.r
***************
*** 283,335 ****
6 | aew.werc.ewr
18 | /?ad=qwe&dw
12 |
! 5 | 1aew.werc.ewr/?ad=qwe&dw
! 6 | 1aew.werc.ewr
18 | /?ad=qwe&dw
12 |
! 6 | 2aew.werc.ewr
12 |
14 | http://
! 5 | 3aew.werc.ewr/?ad=qwe&dw
! 6 | 3aew.werc.ewr
18 | /?ad=qwe&dw
12 |
14 | http://
! 6 | 4aew.werc.ewr
12 |
14 | http://
! 5 | 5aew.werc.ewr:8100/?
! 6 | 5aew.werc.ewr:8100
! 18 | /?
! 12 |
1 | ad
12 | =
1 | qwe
12 | &
1 | dw
12 |
! 5 | 6aew.werc.ewr:8100/?ad=qwe&dw
! 6 | 6aew.werc.ewr:8100
! 18 | /?ad=qwe&dw
! 12 |
! 5 | 7aew.werc.ewr:8100/?ad=qwe&dw=%20%32
! 6 | 7aew.werc.ewr:8100
! 18 | /?ad=qwe&dw=%20%32
! 12 |
! 7 | +4.0e-10
12 |
1 | qwe
12 |
1 | qwe
12 |
1 | qwqwe
12 |
! 20 | 234.435
! 12 |
! 22 | 455
! 12 |
! 20 | 5.005
! 12 |
4 | teodor@stack.net
12 |
16 | qwe-wer
--- 284,380 ----
6 | aew.werc.ewr
18 | /?ad=qwe&dw
12 |
! 12 | 1
! 5 | aew.werc.ewr/?ad=qwe&dw
! 6 | aew.werc.ewr
18 | /?ad=qwe&dw
12 |
! 12 | 2
! 6 | aew.werc.ewr
12 |
14 | http://
! 12 | 3
! 5 | aew.werc.ewr/?ad=qwe&dw
! 6 | aew.werc.ewr
18 | /?ad=qwe&dw
12 |
14 | http://
! 12 | 4
! 6 | aew.werc.ewr
12 |
14 | http://
! 12 | 5
! 6 | aew.werc.ewr
! 12 | :
! 12 | 8
! 12 | 1
! 12 | 0
! 12 | 0
! 12 | /?
1 | ad
12 | =
1 | qwe
12 | &
1 | dw
12 |
! 12 | 6
! 6 | aew.werc.ewr
! 12 | :
! 12 | 8
! 12 | 1
! 12 | 0
! 12 | 0
! 12 | /?
! 1 | ad
! 12 | =
! 1 | qwe
! 12 | &
! 1 | dw
12 |
+ 12 | 7
+ 6 | aew.werc.ewr
+ 12 | :
+ 12 | 8
+ 12 | 1
+ 12 | 0
+ 12 | 0
+ 12 | /?
+ 1 | ad
+ 12 | =
+ 1 | qwe
+ 12 | &
+ 1 | dw
+ 12 | =%
+ 12 | 2
+ 12 | 0%
+ 12 | 3
+ 12 | 2
+ 12 | +
+ 12 | 4.
+ 12 | 0
+ 1 | e
+ 12 | -
+ 12 | 1
+ 12 | 0
1 | qwe
12 |
1 | qwe
12 |
1 | qwqwe
12 |
! 12 | 2
! 12 | 3
! 12 | 4.
! 12 | 4
! 12 | 3
! 12 | 5
! 12 | 4
! 12 | 5
! 12 | 5
! 12 | 5.
! 12 | 0
! 12 | 0
! 12 | 5
4 | teodor@stack.net
12 |
16 | qwe-wer
***************
*** 352,373 ****
12 |
13 | <werrwe>
12 |
! 3 | ewr1
! 12 | >
! 3 | ewri2
12 |
! 13 | <a href="qwe<qwe>">
! 12 | +
|
19 | /usr/local/fff
12 |
! 19 | /awdf/dwqe/4325
! 12 |
19 | rewt/ewr
12 |
1 | wefjn
12 |
! 19 | /wqe-324/ewr
12 |
19 | gist.h
12 |
--- 397,432 ----
12 |
13 | <werrwe>
12 |
! 1 | ewr
! 12 | 1>
! 1 | ewri
! 12 | 2
! 12 | <
! 1 | a
12 |
! 1 | href
! 12 | ="
! 1 | qwe
! 13 | <qwe>
! 12 | "> +
|
19 | /usr/local/fff
12 |
! 19 | /awdf/dwqe
! 12 | /
! 12 | 4
! 12 | 3
! 12 | 2
! 12 | 5
19 | rewt/ewr
12 |
1 | wefjn
12 |
! 19 | /wqe-
! 12 | 3
! 12 | 2
! 12 | 4
! 19 | /ewr
12 |
19 | gist.h
12 |
***************
*** 377,396 ****
12 | .
1 | readline
12 |
! 20 | 4.2
! 12 |
! 20 | 4.2
! 12 | .
! 20 | 4.2
! 12 | ,
1 | readline
! 20 | -4.2
! 12 |
1 | readline
! 20 | -4.2
! 12 | .
! 22 | 234
! 12 | +
|
12 | <
1 | i
--- 436,458 ----
12 | .
1 | readline
12 |
! 12 | 4.
! 12 | 2
! 12 | 4.
! 12 | 2.
! 12 | 4.
! 12 | 2,
1 | readline
! 12 | -
! 12 | 4.
! 12 | 2
1 | readline
! 12 | -
! 12 | 4.
! 12 | 2.
! 12 | 2
! 12 | 3
! 12 | 4 +
|
12 | <
1 | i
***************
*** 404,417 ****
12 |
12 | <>
1 | qwerty
! (133 rows)
SELECT to_tsvector('english', '345 qwe@efd.r '' http://www.com/ http://aew.werc.ewr/?ad=qwe&dw 1aew.werc.ewr/?ad=qwe&dw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwe&dw http://4aew.werc.ewr http://5aew.werc.ewr:8100/? ad=qwe&dw 6aew.werc.ewr:8100/?ad=qwe&dw 7aew.werc.ewr:8100/?ad=qwe&dw=%20%32 +4.0e-10 qwe qwe qwqwe 234.435 455 5.005 teodor@stack.net qwe-wer asdf <fr>qwer jf sdjk<we hjwer <werrwe> ewr1> ewri2 <a href="qwe<qwe>">
/usr/local/fff /awdf/dwqe/4325 rewt/ewr wefjn /wqe-324/ewr gist.h gist.h.c gist.c. readline 4.2 4.2. 4.2, readline-4.2 readline-4.2. 234
<i <b> wow < jqw <> qwerty');
! to_tsvector
! ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
! '+4.0e-10':28 '-4.2':60,62 '/?':18 '/?ad=qwe&dw':7,10,14,24 '/?ad=qwe&dw=%20%32':27 '/awdf/dwqe/4325':48 '/usr/local/fff':47 '/wqe-324/ewr':51 '1aew.werc.ewr':9 '1aew.werc.ewr/?ad=qwe&dw':8 '234':63 '234.435':32 '2aew.werc.ewr':11 '345':1 '3aew.werc.ewr':13 '3aew.werc.ewr/?ad=qwe&dw':12 '4.2':56,57,58 '455':33 '4aew.werc.ewr':15 '5.005':34 '5aew.werc.ewr:8100':17 '5aew.werc.ewr:8100/?':16 '6aew.werc.ewr:8100':23 '6aew.werc.ewr:8100/?ad=qwe&dw':22 '7aew.werc.ewr:8100':26 '7aew.werc.ewr:8100/?ad=qwe&dw=%20%32':25 'ad':19 'aew.werc.ewr':6 'aew.werc.ewr/?ad=qwe&dw':5 'asdf':39 'dw':21 'efd.r':3 'ewr1':45 'ewri2':46 'gist.c':54 'gist.h':52 'gist.h.c':53 'hjwer':44 'jf':41 'jqw':66 'qwe':2,20,29,30,37 'qwe-wer':36 'qwer':40 'qwerti':67 'qwqwe':31 'readlin':55,59,61 'rewt/ewr':49 'sdjk':42 'teodor@stack.net':35 'wefjn':50 'wer':38 'wow':65 'www.com':4
(1 row)
SELECT length(to_tsvector('english', '345 qwe@efd.r '' http://www.com/ http://aew.werc.ewr/?ad=qwe&dw 1aew.werc.ewr/?ad=qwe&dw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwe&dw http://4aew.werc.ewr http://5aew.werc.ewr:8100/? ad=qwe&dw 6aew.werc.ewr:8100/?ad=qwe&dw 7aew.werc.ewr:8100/?ad=qwe&dw=%20%32 +4.0e-10 qwe qwe qwqwe 234.435 455 5.005 teodor@stack.net qwe-wer asdf <fr>qwer jf sdjk<we hjwer <werrwe> ewr1> ewri2 <a href="qwe<qwe>">
--- 466,479 ----
12 |
12 | <>
1 | qwerty
! (195 rows)
SELECT to_tsvector('english', '345 qwe@efd.r '' http://www.com/ http://aew.werc.ewr/?ad=qwe&dw 1aew.werc.ewr/?ad=qwe&dw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwe&dw http://4aew.werc.ewr http://5aew.werc.ewr:8100/? ad=qwe&dw 6aew.werc.ewr:8100/?ad=qwe&dw 7aew.werc.ewr:8100/?ad=qwe&dw=%20%32 +4.0e-10 qwe qwe qwqwe 234.435 455 5.005 teodor@stack.net qwe-wer asdf <fr>qwer jf sdjk<we hjwer <werrwe> ewr1> ewri2 <a href="qwe<qwe>">
/usr/local/fff /awdf/dwqe/4325 rewt/ewr wefjn /wqe-324/ewr gist.h gist.h.c gist.c. readline 4.2 4.2. 4.2, readline-4.2 readline-4.2. 234
<i <b> wow < jqw <> qwerty');
! to_tsvector
! ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
! '/?ad=qwe&dw':6,9,13 '/awdf/dwqe':47 '/ewr':51 '/usr/local/fff':46 '/wqe-':50 'ad':16,20,24 'aew.werc.ewr':5,8,10,12,14,15,19,23 'aew.werc.ewr/?ad=qwe&dw':4,7,11 'asdf':35 'dw':18,22,26 'e':27 'efd.r':2 'ewr':41 'ewri':42 'gist.c':54 'gist.h':52 'gist.h.c':53 'hjwer':40 'href':44 'jf':37 'jqw':60 'qwe':1,17,21,25,28,29,33,45 'qwe-wer':32 'qwer':36 'qwerti':61 'qwqwe':30 'readlin':55,56,57 'rewt/ewr':48 'sdjk':38 'teodor@stack.net':31 'wefjn':49 'wer':34 'wow':59 'www.com':3
(1 row)
SELECT length(to_tsvector('english', '345 qwe@efd.r '' http://www.com/ http://aew.werc.ewr/?ad=qwe&dw 1aew.werc.ewr/?ad=qwe&dw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwe&dw http://4aew.werc.ewr http://5aew.werc.ewr:8100/? ad=qwe&dw 6aew.werc.ewr:8100/?ad=qwe&dw 7aew.werc.ewr:8100/?ad=qwe&dw=%20%32 +4.0e-10 qwe qwe qwqwe 234.435 455 5.005 teodor@stack.net qwe-wer asdf <fr>qwer jf sdjk<we hjwer <werrwe> ewr1> ewri2 <a href="qwe<qwe>">
***************
*** 419,425 ****
<i <b> wow < jqw <> qwerty'));
length
--------
! 53
(1 row)
-- ts_debug
--- 481,487 ----
<i <b> wow < jqw <> qwerty'));
length
--------
! 34
(1 row)
-- ts_debug
***************
*** 430,441 ****
asciiword | Word, all ASCII | abc | {english_stem} | english_stem | {abc}
entity | XML entity | &nm1; | {} | |
asciiword | Word, all ASCII | def | {english_stem} | english_stem | {def}
! entity | XML entity | © | {} | |
asciiword | Word, all ASCII | ghi | {english_stem} | english_stem | {ghi}
! entity | XML entity | õ | {} | |
asciiword | Word, all ASCII | jkl | {english_stem} | english_stem | {jkl}
tag | XML tag | </myns:foo-bar_baz.blurfl> | {} | |
! (9 rows)
-- check parsing of URLs
SELECT * from ts_debug('english', 'http://www.harewoodsolutions.co.uk/press.aspx</span>');
--- 492,508 ----
asciiword | Word, all ASCII | abc | {english_stem} | english_stem | {abc}
entity | XML entity | &nm1; | {} | |
asciiword | Word, all ASCII | def | {english_stem} | english_stem | {def}
! blank | Space symbols | &# | {} | |
! asciiword | Word, all ASCII | xa | {english_stem} | english_stem | {xa}
! blank | Space symbols | 9; | {} | |
asciiword | Word, all ASCII | ghi | {english_stem} | english_stem | {ghi}
! blank | Space symbols | &# | {} | |
! blank | Space symbols | 2 | {} | |
! blank | Space symbols | 4 | {} | |
! blank | Space symbols | 5; | {} | |
asciiword | Word, all ASCII | jkl | {english_stem} | english_stem | {jkl}
tag | XML tag | </myns:foo-bar_baz.blurfl> | {} | |
! (14 rows)
-- check parsing of URLs
SELECT * from ts_debug('english', 'http://www.harewoodsolutions.co.uk/press.aspx</span>');
***************
*** 449,479 ****
(5 rows)
SELECT * from ts_debug('english', 'http://aew.wer0c.ewr/id?ad=qwe&dw<span>');
! alias | description | token | dictionaries | dictionary | lexemes
! ----------+---------------+----------------------------+--------------+------------+------------------------------
! protocol | Protocol head | http:// | {} | |
! url | URL | aew.wer0c.ewr/id?ad=qwe&dw | {simple} | simple | {aew.wer0c.ewr/id?ad=qwe&dw}
! host | Host | aew.wer0c.ewr | {simple} | simple | {aew.wer0c.ewr}
! url_path | URL path | /id?ad=qwe&dw | {simple} | simple | {/id?ad=qwe&dw}
! tag | XML tag | <span> | {} | |
! (5 rows)
SELECT * from ts_debug('english', 'http://5aew.werc.ewr:8100/?');
! alias | description | token | dictionaries | dictionary | lexemes
! ----------+---------------+----------------------+--------------+------------+------------------------
! protocol | Protocol head | http:// | {} | |
! url | URL | 5aew.werc.ewr:8100/? | {simple} | simple | {5aew.werc.ewr:8100/?}
! host | Host | 5aew.werc.ewr:8100 | {simple} | simple | {5aew.werc.ewr:8100}
! url_path | URL path | /? | {simple} | simple | {/?}
! (4 rows)
SELECT * from ts_debug('english', '5aew.werc.ewr:8100/?xx');
! alias | description | token | dictionaries | dictionary | lexemes
! ----------+-------------+------------------------+--------------+------------+--------------------------
! url | URL | 5aew.werc.ewr:8100/?xx | {simple} | simple | {5aew.werc.ewr:8100/?xx}
! host | Host | 5aew.werc.ewr:8100 | {simple} | simple | {5aew.werc.ewr:8100}
! url_path | URL path | /?xx | {simple} | simple | {/?xx}
! (3 rows)
-- to_tsquery
SELECT to_tsquery('english', 'qwe & sKies ');
--- 516,559 ----
(5 rows)
SELECT * from ts_debug('english', 'http://aew.wer0c.ewr/id?ad=qwe&dw<span>');
! alias | description | token | dictionaries | dictionary | lexemes
! ----------+---------------+--------------------+--------------+------------+----------------------
! protocol | Protocol head | http:// | {} | |
! host | Host | aew.wer | {simple} | simple | {aew.wer}
! blank | Space symbols | 0 | {} | |
! url | URL | c.ewr/id?ad=qwe&dw | {simple} | simple | {c.ewr/id?ad=qwe&dw}
! host | Host | c.ewr | {simple} | simple | {c.ewr}
! url_path | URL path | /id?ad=qwe&dw | {simple} | simple | {/id?ad=qwe&dw}
! tag | XML tag | <span> | {} | |
! (7 rows)
SELECT * from ts_debug('english', 'http://5aew.werc.ewr:8100/?');
! alias | description | token | dictionaries | dictionary | lexemes
! ----------+---------------+--------------+--------------+------------+----------------
! protocol | Protocol head | http:// | {} | |
! blank | Space symbols | 5 | {} | |
! host | Host | aew.werc.ewr | {simple} | simple | {aew.werc.ewr}
! blank | Space symbols | : | {} | |
! blank | Space symbols | 8 | {} | |
! blank | Space symbols | 1 | {} | |
! blank | Space symbols | 0 | {} | |
! blank | Space symbols | 0 | {} | |
! blank | Space symbols | /? | {} | |
! (9 rows)
SELECT * from ts_debug('english', '5aew.werc.ewr:8100/?xx');
! alias | description | token | dictionaries | dictionary | lexemes
! -----------+-----------------+--------------+----------------+--------------+----------------
! blank | Space symbols | 5 | {} | |
! host | Host | aew.werc.ewr | {simple} | simple | {aew.werc.ewr}
! blank | Space symbols | : | {} | |
! blank | Space symbols | 8 | {} | |
! blank | Space symbols | 1 | {} | |
! blank | Space symbols | 0 | {} | |
! blank | Space symbols | 0 | {} | |
! blank | Space symbols | /? | {} | |
! asciiword | Word, all ASCII | xx | {english_stem} | english_stem | {xx}
! (9 rows)
-- to_tsquery
SELECT to_tsquery('english', 'qwe & sKies ');
***************
*** 519,527 ****
(1 row)
SELECT plainto_tsquery('english', 'the and z 1))& fghj');
! plainto_tsquery
! --------------------
! 'z' & '1' & 'fghj'
(1 row)
SELECT plainto_tsquery('english', 'foo bar') && plainto_tsquery('english', 'asd');
--- 599,607 ----
(1 row)
SELECT plainto_tsquery('english', 'the and z 1))& fghj');
! plainto_tsquery
! -----------------
! 'z' & 'fghj'
(1 row)
SELECT plainto_tsquery('english', 'foo bar') && plainto_tsquery('english', 'asd');
***************
*** 1061,1067 ****
SELECT count(*) FROM test_tsvector WHERE a @@ to_tsquery('345&qwerty');
count
-------
! 1
(1 row)
UPDATE test_tsvector SET t = null WHERE t = '345 qwerty';
--- 1141,1147 ----
SELECT count(*) FROM test_tsvector WHERE a @@ to_tsquery('345&qwerty');
count
-------
! 0
(1 row)
UPDATE test_tsvector SET t = null WHERE t = '345 qwerty';
***************
*** 1075,1081 ****
SELECT count(*) FROM test_tsvector WHERE a @@ to_tsquery('345&qwerty');
count
-------
! 1
(1 row)
-- test finding items in GIN's pending list
--- 1155,1161 ----
SELECT count(*) FROM test_tsvector WHERE a @@ to_tsquery('345&qwerty');
count
-------
! 0
(1 row)
-- test finding items in GIN's pending list
======================================================================
*** /pub/devel/postgresql/postgresql-9.3beta1-1/src/postgresql-9.3beta1/src/test/regress/expected/without_oid.out 2013-05-06 22:57:06.000000000 +0200
--- /pub/devel/postgresql/postgresql-9.3beta1-1/build/src/test/regress/results/without_oid.out 2013-06-10 10:22:39.130668700 +0200
***************
*** 47,52 ****
--- 47,53 ----
LINE 1: SELECT count(oid) FROM wo;
^
VACUUM ANALYZE wi;
+ WARNING: could not open statistics file "pg_stat_tmp/global.stat": Device or resource busy
VACUUM ANALYZE wo;
SELECT min(relpages) < max(relpages), min(reltuples) - max(reltuples)
FROM pg_class
======================================================================
Import Notes
Reply to msg id not found: 5137C75D.8020704@dunslane.netReference msg id not found: 5137C096.8070408@gmail.comReference msg id not found: 5137C75D.8020704@dunslane.net
On Mon, Jun 10, 2013 at 11:08:36AM +0200, marco atzeri wrote:
Il 3/6/2013 11:46 PM, Andrew Dunstan ha scritto:
Excellent. Will test it out soon.
cheers
andrew
Andrew,
please find attached a full patch for cygwin relative to 9.3beta1 :- DLLTOLL/DLLWRAP are not used anymore, replaced
by gcc also for postgres.exe (*)
- DLL versioning is addedCheck failures:
- prepared_xacts is still freezing
The cygwin failure you highlighted was solved,
so it should be something else
- attached the 2 regressions diffs
tsearch ... FAILED
without_oid ... FAILED
The second one seems a new one, not sure cygwin specific
Andrew, should this configuration/code patch be applied to 9.4?
/messages/by-id/51B59794.3000500@gmail.com
I think we would have to make Cygwin-specific regression output to
handle the regression failures, but frankly I am not even sure if they
are right.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
Andrew, should this configuration/code patch be applied to 9.4?
I think we would have to make Cygwin-specific regression output to
handle the regression failures, but frankly I am not even sure if they
are right.
Those regression failures certainly say there is something broken in
the submitter's build, so this needs to be taken with a grain of salt.
I'm not qualified to evaluate the proposed changes, but I wonder why
they're needed given that we have successful cygwin builds in the
buildfarm.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 23, 2014 at 10:48:01PM -0500, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Andrew, should this configuration/code patch be applied to 9.4?
I think we would have to make Cygwin-specific regression output to
handle the regression failures, but frankly I am not even sure if they
are right.Those regression failures certainly say there is something broken in
the submitter's build, so this needs to be taken with a grain of salt.
I'm not qualified to evaluate the proposed changes, but I wonder why
they're needed given that we have successful cygwin builds in the
buildfarm.
Yes, that confuses me too. Unless we get more details, we should ignore
the patches. Thanks.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/23/2014 10:50 PM, Bruce Momjian wrote:
On Thu, Jan 23, 2014 at 10:48:01PM -0500, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Andrew, should this configuration/code patch be applied to 9.4?
/messages/by-id/51B59794.3000500@gmail.com
I think we would have to make Cygwin-specific regression output to
handle the regression failures, but frankly I am not even sure if they
are right.Those regression failures certainly say there is something broken in
the submitter's build, so this needs to be taken with a grain of salt.
I'm not qualified to evaluate the proposed changes, but I wonder why
they're needed given that we have successful cygwin builds in the
buildfarm.Yes, that confuses me too. Unless we get more details, we should ignore
the patches. Thanks.
AFAICT the regression is in Cygwin. The buildfarm passes because it's
using an oldish Cygwin release, 1.7.7 rather than the current 1.7.27. I
have brought the regression the athe attention of the Cygwin people in
the past, but without response.
The build system changes have slipped off my radar, unfortunately. Not
sure when I can get to them.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 24/01/2014 05:28, Andrew Dunstan wrote:
On 01/23/2014 10:50 PM, Bruce Momjian wrote:
On Thu, Jan 23, 2014 at 10:48:01PM -0500, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Andrew, should this configuration/code patch be applied to 9.4?
/messages/by-id/51B59794.3000500@gmail.com
I think we would have to make Cygwin-specific regression output to
handle the regression failures, but frankly I am not even sure if they
are right.Those regression failures certainly say there is something broken in
the submitter's build, so this needs to be taken with a grain of salt.
I'm not qualified to evaluate the proposed changes, but I wonder why
they're needed given that we have successful cygwin builds in the
buildfarm.Yes, that confuses me too. Unless we get more details, we should ignore
the patches. Thanks.
Andrew,
nice to see, the question rises again.
I dropped from the pgsql-hackers@postgresql.org some time ago,
as no one was following the issue; I just rejoined.
As explained here:
http://cygwin.com/ml/cygwin/2013-03/msg00217.html
http://cygwin.com/ml/cygwin/2013-03/msg00050.html
1) Using DLLTOOL/DLLWRAP
"postgresql dll's allocation table are partially wrong,
so they fail at load after a rebase."
the build farm can not test this rebase failure, as it will happen after
installation at any rebase.
DLLTOOL/DLLWRAP usage is "really" deprecated on cygwin as it produces
damaged binaries that
2) I am the currently package mantainer for cygwin
last I packged was postgresql-9.2.4
9.3.2 is on my TODO list
AFAICT the regression is in Cygwin. The buildfarm passes because it's
using an oldish Cygwin release, 1.7.7 rather than the current 1.7.27. I
have brought the regression the athe attention of the Cygwin people in
the past, but without response.
which issue ?
During my package tests I have only two issues:
tsearch ... FAILED
and
test: prepared_xacts
must be skipped as it never completes
The build system changes have slipped off my radar, unfortunately. Not
sure when I can get to them.
Regars
Marco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/24/2014 01:20 AM, Marco Atzeri wrote:
AFAICT the regression is in Cygwin. The buildfarm passes because it's
using an oldish Cygwin release, 1.7.7 rather than the current 1.7.27. I
have brought the regression the athe attention of the Cygwin people in
the past, but without response.which issue ?
During my package tests I have only two issues:tsearch ... FAILED
and
test: prepared_xacts
must be skipped as it never completes
Those two issues need to be fixed. And yes, they are regressions from my
Cygwin 1.7.7 setup where they pass consistently, just about every day.
See <http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=brolga&br=HEAD>
You don't get to choose which regression tests you're going to pass and
which you're not. Disabling the tests or providing nonsensical results
files are unacceptable. This is a Cygwin behavior issue and needs to be
fixed.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 24/01/2014 12:56, Andrew Dunstan wrote:
On 01/24/2014 01:20 AM, Marco Atzeri wrote:
AFAICT the regression is in Cygwin. The buildfarm passes because it's
using an oldish Cygwin release, 1.7.7 rather than the current 1.7.27. I
have brought the regression the athe attention of the Cygwin people in
the past, but without response.which issue ?
During my package tests I have only two issues:tsearch ... FAILED
and
test: prepared_xacts
must be skipped as it never completesThose two issues need to be fixed. And yes, they are regressions from my
Cygwin 1.7.7 setup where they pass consistently, just about every day.
See <http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=brolga&br=HEAD>
1.7.7 is 3.5 years hold.
In the mean time we added 64 bit and moved to gcc-4.8.x
You don't get to choose which regression tests you're going to pass and
which you're not. Disabling the tests or providing nonsensical results
files are unacceptable. This is a Cygwin behavior issue and needs to be
fixed.
Distributing broken binary that crashes after standard rebase, it is
also not acceptable and it is also worst.
Your farm is not testing this case, I presume.
Until I took over there was NO recent cygwin package at all in
the distribution, so do not complain that my binary is not perfect,
I already know, but for me almost working is better than NOT available
or BROKEN.
cheers
andrew
I am available to work on tests regression, but I am not a postgresql
expert so do not expect all the job from my side.
Regards
Marco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/24/2014 07:50 AM, Marco Atzeri wrote:
Those two issues need to be fixed. And yes, they are regressions from my
Cygwin 1.7.7 setup where they pass consistently, just about every day.
See
<http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=brolga&br=HEAD>1.7.7 is 3.5 years hold.
In the mean time we added 64 bit and moved to gcc-4.8.x
No doubt, but that doesn't mean that extra things failing is OK.
You don't get to choose which regression tests you're going to pass and
which you're not. Disabling the tests or providing nonsensical results
files are unacceptable. This is a Cygwin behavior issue and needs to be
fixed.Distributing broken binary that crashes after standard rebase, it is
also not acceptable and it is also worst.
Your farm is not testing this case, I presume.
Quite so. But this is not a case of either/or.
I have now tested the central part of the proposed changes on both old
and new Cygwin installations, and they appear to work.
I'm going to commit them and backpatch back to 9.0, which is where we
currently have buildfarm coverage (and 8.4 will be at EOL in a few
months anyway). That will take care of your rebase issue.
That leaves several issues to be handled:
* LDAP libraries - the way you have proposed surely isn't right. What
we want is something more like this in the Makefile.global.in:
ifeq ($(PORTNAME), cygwin)
libpq_pgport += $(LDAP_LIBS_FE)
endif
* isolation tests fail with an indefinite hang on newer Cygwin
* prepared_xacts test fails with an indefinite hang on newer Cygwin if
run in parallel with other tests
* tsearch tests fail on non-C locale (or at least on en_US.utf8). It
turns out this is actually an old bug, and can be reproduced on my
old Cygwin instance. I wonder if it's caused by faulty locale files?
Really, for a properly working port all these need to be fixed.
I am available to work on tests regression, but I am not a postgresql
expert so do not expect all the job from my side.
We can help you some, but very few people in the community run Cygwin,
and my time to spend on it is fairly limited.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 25/01/2014 19:23, Andrew Dunstan wrote:
On 01/24/2014 07:50 AM, Marco Atzeri wrote:
Those two issues need to be fixed. And yes, they are regressions from my
Cygwin 1.7.7 setup where they pass consistently, just about every day.
See
<http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=brolga&br=HEAD>1.7.7 is 3.5 years hold.
In the mean time we added 64 bit and moved to gcc-4.8.xNo doubt, but that doesn't mean that extra things failing is OK.
Andrew,
I never wrote that.
You don't get to choose which regression tests you're going to pass and
which you're not. Disabling the tests or providing nonsensical results
files are unacceptable. This is a Cygwin behavior issue and needs to be
fixed.
some indication where to look for in the code will help.
Distributing broken binary that crashes after standard rebase, it is
also not acceptable and it is also worst.
Your farm is not testing this case, I presume.Quite so. But this is not a case of either/or.
No, but I spent a lot of time on understanding that DLLTOLL/DLLWRAP
produce buggy binaries, and that was a CRITICAL failure.
I have now tested the central part of the proposed changes on both old
and new Cygwin installations, and they appear to work.I'm going to commit them and backpatch back to 9.0, which is where we
currently have buildfarm coverage (and 8.4 will be at EOL in a few
months anyway). That will take care of your rebase issue.That leaves several issues to be handled:
* LDAP libraries - the way you have proposed surely isn't right. What
we want is something more like this in the Makefile.global.in:
ifeq ($(PORTNAME), cygwin)
libpq_pgport += $(LDAP_LIBS_FE)
endif
I will test in this way. I have no preferance on
the implemented solution.
* isolation tests fail with an indefinite hang on newer Cygwin
* prepared_xacts test fails with an indefinite hang on newer Cygwin if
run in parallel with other tests
It hangs also stand alone. I guess some race or deadlock issue.
* tsearch tests fail on non-C locale (or at least on en_US.utf8). It
turns out this is actually an old bug, and can be reproduced on my
old Cygwin instance. I wonder if it's caused by faulty locale files?
Tested tsearch with
"export LANG=C" works
"export LANG=C.utf8" fails
"export LANG=it_IT" works
"export LANG=it_IT.utf8" fails
faulty locale or wrong assumption on utf8 implementation ?
Really, for a properly working port all these need to be fixed.
No objection. Step by step
I am available to work on tests regression, but I am not a postgresql
expert so do not expect all the job from my side.We can help you some, but very few people in the community run Cygwin,
and my time to spend on it is fairly limited.
For the time being, I can run tests and builds.
cheers
andrew
cheers
Marco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 25/01/2014 22:42, Marco Atzeri wrote:
On 25/01/2014 19:23, Andrew Dunstan wrote:
On 01/24/2014 07:50 AM, Marco Atzeri wrote:
* LDAP libraries - the way you have proposed surely isn't right. What
we want is something more like this in the Makefile.global.in:
ifeq ($(PORTNAME), cygwin)
libpq_pgport += $(LDAP_LIBS_FE)
endifI will test in this way. I have no preferance on
the implemented solution.
your proposal builds fine.
----------------------------------------------------------------
--- origsrc/postgresql-9.3.2/src/Makefile.global.in 2013-12-02
21:57:48.000000000 +0100
+++ src/postgresql-9.3.2/src/Makefile.global.in 2014-01-25
22:46:36.484816700 +0100
@@ -508,6 +508,11 @@ ifeq ($(PORTNAME),win32)
LIBS += -lws2_32 -lshfolder
endif+# missing for link on cygwin ?
+ifeq ($(PORTNAME),cygwin)
+libpq_pgport += $(LDAP_LIBS_FE)
+endif
+
# Not really standard libc functions, used by the backend.
----------------------------------------------------------------Of course no difference on test results, as expected
Attached full patch as I am currently testing on 9.3.2
Regards
Marco
Attachments:
postgresql-9.3.2-2.src.patchtext/plain; charset=windows-1252; name=postgresql-9.3.2-2.src.patchDownload
--- origsrc/postgresql-9.3.2/src/Makefile.global.in 2013-12-02 21:57:48.000000000 +0100
+++ src/postgresql-9.3.2/src/Makefile.global.in 2014-01-25 22:46:36.484816700 +0100
@@ -508,6 +508,11 @@ ifeq ($(PORTNAME),win32)
LIBS += -lws2_32 -lshfolder
endif
+# missing for link on cygwin ?
+ifeq ($(PORTNAME),cygwin)
+libpq_pgport += $(LDAP_LIBS_FE)
+endif
+
# Not really standard libc functions, used by the backend.
TAS = @TAS@
--- origsrc/postgresql-9.3.2/src/Makefile.shlib 2013-12-02 21:57:48.000000000 +0100
+++ src/postgresql-9.3.2/src/Makefile.shlib 2014-01-24 23:05:08.601675200 +0100
@@ -281,8 +281,9 @@ ifeq ($(PORTNAME), unixware)
endif
ifeq ($(PORTNAME), cygwin)
+ LINK.shared = $(CC) -shared
ifdef SO_MAJOR_VERSION
- shlib = cyg$(NAME)$(DLSUFFIX)
+ shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX)
endif
haslibarule = yes
endif
@@ -371,6 +372,12 @@ else # PORTNAME == cygwin || PORTNAME ==
# If SHLIB_EXPORTS is set, the rules below will build a .def file from
# that. Else we build a temporary one here.
+ifeq ($(PORTNAME), cygwin)
+$(shlib) $(stlib): $(OBJS) | $(SHLIB_PREREQS)
+ $(CC) $(CFLAGS) -shared -o $(shlib) -Wl,--out-implib=$(stlib) $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) $(LDAP_LIBS_BE)
+
+
+else
ifeq (,$(SHLIB_EXPORTS))
DLL_DEFFILE = lib$(NAME)dll.def
exports_file = $(DLL_DEFFILE)
@@ -387,6 +394,7 @@ $(shlib): $(OBJS) $(DLL_DEFFILE) | $(SHL
$(stlib): $(shlib) $(DLL_DEFFILE) | $(SHLIB_PREREQS)
$(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(DLL_DEFFILE) --output-lib $@
+endif # PORTNAME == cygwin
endif # PORTNAME == cygwin || PORTNAME == win32
--- origsrc/postgresql-9.3.2/src/backend/Makefile 2013-12-02 21:57:48.000000000 +0100
+++ src/postgresql-9.3.2/src/backend/Makefile 2014-01-24 23:05:08.621675200 +0100
@@ -62,18 +62,8 @@ endif
ifeq ($(PORTNAME), cygwin)
-postgres: $(OBJS) postgres.def libpostgres.a
- $(DLLTOOL) --dllname $@$(X) --output-exp $@.exp --def postgres.def
- $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -o $@$(X) -Wl,--base-file,$@.base $@.exp $(call expand_subsys,$(OBJS)) $(LIBS)
- $(DLLTOOL) --dllname $@$(X) --base-file $@.base --output-exp $@.exp --def postgres.def
- $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -Wl,--stack,$(WIN32_STACK_RLIMIT) -o $@$(X) $@.exp $(call expand_subsys,$(OBJS)) $(LIBS)
- rm -f $@.exp $@.base
-
-postgres.def: $(OBJS)
- $(DLLTOOL) --export-all --output-def $@ $(call expand_subsys,$^)
-
-libpostgres.a: postgres.def
- $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@
+postgres libpostgres.a: $(OBJS)
+ $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) $(export_dynamic) $(call expand_subsys,$^) $(LIBS) -o $@ -Wl,--stack,$(WIN32_STACK_RLIMIT) -Wl,--export-all-symbols -Wl,--out-implib=libpostgres.a
endif # cygwin
--- origsrc/postgresql-9.3.2/src/interfaces/libpq/Makefile 2013-12-02 21:57:48.000000000 +0100
+++ src/postgresql-9.3.2/src/interfaces/libpq/Makefile 2014-01-24 23:05:08.621675200 +0100
@@ -45,7 +45,7 @@ OBJS += ip.o md5.o
OBJS += encnames.o wchar.o
ifeq ($(PORTNAME), cygwin)
-override shlib = cyg$(NAME)$(DLSUFFIX)
+override shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX)
endif
ifeq ($(PORTNAME), win32)
--- origsrc/postgresql-9.3.2/src/makefiles/Makefile.cygwin 2013-12-02 21:57:48.000000000 +0100
+++ src/postgresql-9.3.2/src/makefiles/Makefile.cygwin 2014-01-24 23:05:08.641675200 +0100
@@ -1,6 +1,4 @@
# src/makefiles/Makefile.cygwin
-DLLTOOL= dlltool
-DLLWRAP= dllwrap
ifdef PGXS
BE_DLLLIBS= -L$(libdir) -lpostgres
else
@@ -44,6 +42,4 @@ endif
# Rule for building a shared library from a single .o file
%.dll: %.o
- $(DLLTOOL) --export-all --output-def $*.def $<
- $(DLLWRAP) -o $@ --def $*.def $< $(LDFLAGS) $(LDFLAGS_SL) $(BE_DLLLIBS)
- rm -f $*.def
+ $(CC) $(CFLAGS) -shared -o $@ $< $(LDFLAGS) $(LDFLAGS_SL) $(BE_DLLLIBS)
--- origsrc/postgresql-9.3.2/src/test/regress/parallel_schedule 2013-12-02 21:57:48.000000000 +0100
+++ src/postgresql-9.3.2/src/test/regress/parallel_schedule 2014-01-24 23:05:08.651675200 +0100
@@ -78,7 +78,8 @@ ignore: random
# ----------
# Another group of parallel tests
# ----------
-test: select_into select_distinct select_distinct_on select_implicit select_having subselect union case join aggregates transactions random portals arrays btree_index hash_index update namespace prepared_xacts delete
+test: select_into select_distinct select_distinct_on select_implicit select_having subselect union case join aggregates transactions random portals arrays btree_index hash_index update namespace delete
+# test: prepared_xacts
# ----------
# Another group of parallel tests
On 01/25/2014 01:23 PM, Andrew Dunstan wrote:
I have now tested the central part of the proposed changes on both old
and new Cygwin installations, and they appear to work.I'm going to commit them and backpatch back to 9.0, which is where we
currently have buildfarm coverage (and 8.4 will be at EOL in a few
months anyway). That will take care of your rebase issue.
That part is done. Reliance on dllwrap is a thing of the past.
That leaves several issues to be handled:
* LDAP libraries - the way you have proposed surely isn't right. What
we want is something more like this in the Makefile.global.in:
ifeq ($(PORTNAME), cygwin)
libpq_pgport += $(LDAP_LIBS_FE)
endif
Unless someone comes up with a better answer than this I'm going to
commit it too.
* isolation tests fail with an indefinite hang on newer Cygwin
* prepared_xacts test fails with an indefinite hang on newer Cygwin if
run in parallel with other tests
* tsearch tests fail on non-C locale (or at least on en_US.utf8). It
turns out this is actually an old bug, and can be reproduced on my
old Cygwin instance. I wonder if it's caused by faulty locale files?
And these are where we need help, especially from the Cygwin community.
The fact that things that work on older Cygwins now fail is annoying.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/02/2014 22:57, Andrew Dunstan wrote:
On 01/25/2014 01:23 PM, Andrew Dunstan wrote:
* isolation tests fail with an indefinite hang on newer Cygwin
* prepared_xacts test fails with an indefinite hang on newer Cygwin if
run in parallel with other tests
* tsearch tests fail on non-C locale (or at least on en_US.utf8). It
turns out this is actually an old bug, and can be reproduced on my
old Cygwin instance. I wonder if it's caused by faulty locale files?
Andrew,
is it possible the tsearch test never worked on en_US.utf8
but only on C locale ?
See my finding on
/messages/by-id/52ED5627.4070005@gmail.com
And these are where we need help, especially from the Cygwin community.
The fact that things that work on older Cygwins now fail is annoying.cheers
andrew
Marco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/01/2014 05:12 PM, Marco Atzeri wrote:
On 01/02/2014 22:57, Andrew Dunstan wrote:
On 01/25/2014 01:23 PM, Andrew Dunstan wrote:
* isolation tests fail with an indefinite hang on newer Cygwin
* prepared_xacts test fails with an indefinite hang on newer Cygwin if
run in parallel with other tests* tsearch tests fail on non-C locale (or at least on en_US.utf8). It
turns out this is actually an old bug, and can be reproduced on my
old Cygwin instance. I wonder if it's caused by faulty locale files?Andrew,
is it possible the tsearch test never worked on en_US.utf8
but only on C locale ?
Yes, that's more or less what I said, I thought.
Maybe we need to test this on other Windows systems in non-C encodings.
Let's make sure it's only a Cygwin problem.
I'll work on that. You should try to concentrate on the thinks like
prepared_xacts and isolation_test that we know don't work ONLY on Cygwin.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
On 02/01/2014 05:12 PM, Marco Atzeri wrote:
is it possible the tsearch test never worked on en_US.utf8
but only on C locale ?
Yes, that's more or less what I said, I thought.
Maybe we need to test this on other Windows systems in non-C encodings.
Let's make sure it's only a Cygwin problem.
I'll work on that. You should try to concentrate on the thinks like
prepared_xacts and isolation_test that we know don't work ONLY on Cygwin.
Please test the patch I just posted in the pgsql-bugs thread. It looks
to me like there are bugs in both the C and non-C locale cases, but only
the latter case would be exercised by our regression tests, since we
don't use any non-ASCII characters in the tests.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/01/2014 05:46 PM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 02/01/2014 05:12 PM, Marco Atzeri wrote:
is it possible the tsearch test never worked on en_US.utf8
but only on C locale ?Yes, that's more or less what I said, I thought.
Maybe we need to test this on other Windows systems in non-C encodings.
Let's make sure it's only a Cygwin problem.
I'll work on that. You should try to concentrate on the thinks like
prepared_xacts and isolation_test that we know don't work ONLY on Cygwin.Please test the patch I just posted in the pgsql-bugs thread. It looks
to me like there are bugs in both the C and non-C locale cases, but only
the latter case would be exercised by our regression tests, since we
don't use any non-ASCII characters in the tests.
This is commit 082c0dfa140b5799bc7eb574d68610dcfaa619ba and friends, right?
If so, it appears to have done the trick. brolga is now happy running
tsearch with en_US.utf8:
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=brolga&dt=2014-02-03%2011%3A26%3A10&stg=install-check-en_US.utf8>
Cool.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers