[BUGS] [PATCH v3] Use CC atomic builtins on ARM
Hello Tom, all,
happy new year everyone!
Tom Lane [2011-12-20 21:14 -0500]:
> So I'm thinking that removing the swpb ASM option is not such a good
> idea. We could possibly test for __sync_lock_test_and_set first, and
> only use swpb if we're on ARM and don't have the builtin.
Tom Lane [2011-12-21 10:55 -0500]:
> Yeah, that was another thing I found worrisome while googling: there
> were a disturbingly large number of claims that __sync_lock_test_and_set
> and/or __sync_lock_release were flat-out broken on various combinations
> of gcc version and platform. After reading that, there is no way at all
> that I'd accept your original patch to use these functions everywhere.
>
> For the moment I'm inclined to consider using these functions *only* on
> ARM, so as to limit our exposure to such bugs. That would also limit
> the risk of using an inappropriate choice of lock width.
OK, fair enough. New patch attached, which does exactly this now.
Third time is the charm!
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Description: Use gcc/intel cc builtin atomic operations for test-and-set on ARM, if available (http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html). The existing PostgreSQL implementation does not work on thumb2.
Author: Martin Pitt
Index: postgresql-9.1-9.1.2/configure.in
===
--- postgresql-9.1-9.1.2.orig/configure.in 2011-12-01 22:47:20.0 +0100
+++ postgresql-9.1-9.1.2/configure.in 2012-01-07 10:10:51.153609202 +0100
@@ -1522,6 +1522,18 @@
AC_SUBST(LDAP_LIBS_FE)
AC_SUBST(LDAP_LIBS_BE)
+# gcc and intel compiler provide builtin functions for atomic test-and-set
+AC_MSG_CHECKING([whether the C compiler provides atomic builtins])
+AC_TRY_LINK([], [int lock = 0; __sync_lock_test_and_set(&lock, 1); __sync_lock_release(&lock);],
+ [have_cc_atomics="yes"],
+ [have_cc_atomics="no"]
+)
+if test "$have_cc_atomics" = yes; then
+ AC_MSG_RESULT(yes)
+ AC_DEFINE(HAVE_CC_ATOMICS, 1, [Define to 1 if compiler provides atomic builtins])
+else
+ AC_MSG_RESULT(no)
+fi
# This test makes sure that run tests work at all. Sometimes a shared
# library is found by the linker, but the runtime linker can't find it.
Index: postgresql-9.1-9.1.2/configure
===
--- postgresql-9.1-9.1.2.orig/configure 2011-12-01 22:47:20.0 +0100
+++ postgresql-9.1-9.1.2/configure 2012-01-07 10:10:51.177609204 +0100
@@ -23602,6 +23602,69 @@
+# gcc and intel compiler provide builtin functions for atomic test-and-set
+{ $as_echo "$as_me:$LINENO: checking whether the C compiler provides atomic builtins" >&5
+$as_echo_n "checking whether the C compiler provides atomic builtins... " >&6; }
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+
+int
+main ()
+{
+int lock = 0; __sync_lock_test_and_set(&lock, 1); __sync_lock_release(&lock);
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (ac_try="$ac_link"
+case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\""
+$as_echo "$ac_try_echo") >&5
+ (eval "$ac_link") 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } && {
+ test -z "$ac_c_werror_flag" ||
+ test ! -s conftest.err
+ } && test -s conftest$ac_exeext && {
+ test "$cross_compiling" = yes ||
+ $as_test_x conftest$ac_exeext
+ }; then
+ have_cc_atomics="yes"
+else
+ $as_echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ have_cc_atomics="no"
+
+fi
+
+rm -rf conftest.dSYM
+rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \
+ conftest$ac_exeext conftest.$ac_ext
+if test "$have_cc_atomics" = yes; then
+ { $as_echo "$as_me:$LINENO: result: yes" >&5
+$as_echo "yes" >&6; }
+
+cat >>confdefs.h <<\_ACEOF
+#define HAVE_CC_ATOMICS 1
+_ACEOF
+
+else
+ { $as_echo "$as_me:$LINENO: result: no" >&5
+$as_echo "no" >&6; }
+fi
# This test makes sure that run tests work at all. Sometimes a shared
# library is found by the linker, but the runtime linker can't find it.
Index: postgresql-9.1-9.1.2/src/include/pg_config.h.in
===
--- postgresql-9.1-9.1.2.orig/src/include/pg_config.h.in 2011-12-01 22:47:20.0 +0100
+++ postgresql-9.1-9.1.2/src/include/pg_config.h.in 2012-01-07 10:10:51.657609229 +0100
@@ -87,6 +87,9 @@
/* Define to 1 if you have the `cbrt' function. */
#undef HAVE_CBRT
+/* Define to 1 if compiler provides atomic builtins */
+#undef HAVE_CC_ATOMICS
+
/* Define
Re: [BUGS] [PATCH v3] Use CC atomic builtins on ARM
Martin Pitt writes: > Tom Lane [2011-12-21 10:55 -0500]: >> For the moment I'm inclined to consider using these functions *only* on >> ARM, so as to limit our exposure to such bugs. That would also limit >> the risk of using an inappropriate choice of lock width. > OK, fair enough. New patch attached, which does exactly this now. > Third time is the charm! I've got some minor cosmetic complaints about this, but unless anyone's got something substantive I will fix those, apply and back-patch it. There are some folks trying to get a Fedora ARM port running and I think this might help them with Postgres ... http://arm.koji.fedoraproject.org/koji/getfile?taskID=246852&name=build.log regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6388: I can not install postgre Sql
The following bug has been logged on the website: Bug reference: 6388 Logged by: stoian Email address: stoian_cris2...@yahoo.com PostgreSQL version: 8.4.10 Operating system: windows XP Description: I can not install postgre Sql . I get the following message: Sorry, could not install Postgre SQL!. Cause: Output folder: C:\Program Files\PSQLINSTALL top level install dir -->C:\Program Files Is admin account fs=NTFS .NET found Extract: TestFirewall.exe... 100% Extract: TestFirewall.exe.config... 100% Antivirus Installed: True test antivirus returned 1 antivirus installed security center error status: 0 security center status: 4 disabling security center security center error status: 0 security center status: 1 disabled security center seclogon error status: 0 seclogon status: 4 firewall enabled: 0 firewall not enabled postgresql error status: 1060 postgresql status: 0 starting pgsql-8.3 postgresql error status: 1060 postgresql status: 0 postgresql error status: 1060 postgresql status: 0 starting postgresql-8.4 postgresql error status: 1060 postgresql status: 0 postgres installdir: C:\Program Files\PSQLINSTALL running PsqlTestClient try userid: postgres try pass: postgrespass try pass: postgrespass Connection to database failed: -->could not connect to server: Connection refused (0x274D/10061) Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432? <--error 1 testclient return status: 1 testclient return from file: 1 finished PsqlTestClient granting write permission on top level postgres directory found dir try rename C:\Program Files\PostgreSQL\8.4 --> C:\Program Files\PostgreSQL\8.4-prev-2012-02-Jan-00-20-01 Create folder: C:\Program Files\PostgreSQL\8.4-prev-2012-02-Jan-00-20-01 Moving files: C:\Program Files\PostgreSQL\8.4\*.* to C:\Program Files\PostgreSQL\8.4-prev-2012-02-Jan-00-20-01\ Remove folder: C:\Program Files\PostgreSQL\8.4\ renamed dir wrote testfile Delete file: C:\Program Files\PostgreSQL\testfile Extract: postgresql-8.4.1-1-windows.exe... 100% Execute: "C:\Program Files\PSQLINSTALL\postgresql-8.4.1-1-windows.exe" --mode unattended --superpassword postgrespass postgres installdir: C:\Program Files\PSQLINSTALL running PsqlTestClient try userid: postgres try pass: postgrespass try pass: postgrespass Connection to database failed: -->could not connect to server: Connection refused (0x274D/10061) Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432? <--error 1 testclient return status: 1 testclient return from file: 1 finished PsqlTestClient WHAT CAN I DO ? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6387: eror
The following bug has been logged on the website: Bug reference: 6387 Logged by: golodnew Email address: golod...@mail.ru PostgreSQL version: 9.1.1 Operating system: windows xp Description: can't connect to postgres sql (wrong server,port,or firewall enabled?). programma: Xoldem manager 2 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6385: extract epoch at timezone returns wrong value
The following bug has been logged on the website: Bug reference: 6385 Logged by: Sreeraj S Email address: sree...@ordyn.com PostgreSQL version: 9.1.2 Operating system: Windows Vista Professional Description: Below is given psql output - I am in timezone UTC+05:30 (India) as shown by select now() output below. When I give "SELECT extract(epoch from now() );" the output is 1325872658.xxx I would expect a slightly incremented value when after a few seconds I give the command "SELECT extract(epoch from now() at time zone 'utc+05:30');" . Nut I get the value 1325833067.xxx which is the value for utc-05:30 !!! And when I give "SELECT extract(epoch from now() at time zone 'utc-05:30');", I get 1325872672.xxx which is what is expected if I specified timezone +05:30 !!! - psql extract below -- ordprdlic=> select now(); now --- 2012-01-06 23:27:35.663+05:30 (1 row) ordprdlic=> SELECT extract(epoch from now() ); date_part 1325872658.608 (1 row) ordprdlic=> SELECT extract(epoch from now() at time zone 'utc+05:30'); date_part 1325833067.073 (1 row) ordprdlic=> SELECT extract(epoch from now() at time zone 'utc-05:30'); date_part 1325872672.977 (1 row) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6386: PITR never find a consistent recovery point
The following bug has been logged on the website: Bug reference: 6386 Logged by: Max Kunz Email address: max.k...@atip.de PostgreSQL version: 9.0.0 Operating system: CentOs Description: Hello, i've got a Problem during PITR. The Systems stops always with fatal error: FATAL: requested recovery stop point is before consistent recovery point. One system is configured as standby, performing stream and WAL replication. Another system is running in primary mode. I have verified that the standby system performed the basebackup successfully. Hours later I did like to perform a PITR. I use a target_time which is one hour later than stop_basebackup_time. In spite of that fact, i've got the error message. I'm able to start this server in primary mode, but it's not possible to perform a PITR one minute ago. Do you have any idea why the system don't find a consistent point for PITR but for normal startup in primary mode? kind regards Max -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
