Re: [BUGS] BUG #6345: "forget the password for reinstallaion"
On Dec 19, 2011, at 10:49 AM, manojk.softengin...@gmail.com wrote: > The following bug has been logged on the website: > > Bug reference: 6345 > Logged by: manoj > Email address: manojk.softengin...@gmail.com > PostgreSQL version: 9.1.2 > Operating system: window 7 > Description: > > i have downloaded latest version of postgresql ,but due certain anomalies , > i have unistall it , but after some time , i decided to reinsatll it , but > it want pre existing password for installation , i have completely deleted > various files of postgresql including registry cleanup as well but i am > unable to install it again , please help. The installer must be asking about the password for system user 'postgres'. To change the password or delete the user itself, "Right Click MyComputer"-> Click Manage, Select Local Users and Groups, Select Users You will see the user 'postgres' listed there, you can change the password or delete the user. > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Regards, Sachin Srivastava EnterpriseDB, the Enterprise PostgreSQL company. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
1. Yes, obviously I launched that command when the program was blocked. 2. The system release is "SUSE SLES 10 SP4 64 BIT" with kernel 2.6.16.60. Maybe it's not the last release but it can justify the blocks ? In other systems (VMWARE) the same system work fine. What you suspect ? libpq ? linux release ? hardware ? If you need other informations let me know. Regards, Andrea -Messaggio originale- Da: Craig Ringer [mailto:ring...@ringerc.id.au] Inviato: sabato 17 dicembre 2011 7.19 A: Andrea Grassi Cc: pgsql-bugs@postgresql.org Oggetto: Re: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function On 16/12/2011 10:10 PM, Andrea Grassi wrote: > The client program and the postgres server are on the same host, client > connects to 127.0.0.1. > In the meantime, my original program blocks (not my example but very probably > the reasons are the same). > > I typed "ps -C testprogramname -o wchan:80=" and the output was only a single > dash ( "-" ). That means it's not waiting in a kernel call right now. Was the program in the hung state you've observed at the time you ran the command? Its output would only be interesting when it's hung. > I searched for the complete stack in /proc/$pid/stack (where $pid) was the > pid of my process but this file doesn't exists !! Why ? Old kernel, maybe? You're running on some kind of enterprise-y distro, so who knows how ancient half the stuff in there is. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote: >> It probably makes sense to use it on any platform where it's >> defined. Presumably an implementation provided by the compiler is >> always going to be at least as good as any magic assembler >> incantations we can come up with. > > I agree. How about a patch like this? It uses builtin atomics if > available, and falls back to the custom implementations if not. -1. Absent some evidence that gcc's implementations are superior to ours, I think we should not change stuff that works now. That's likely to lead to subtle bugs that are hard to find and perhaps dependent on the exact compiler version used. But I'm completely cool with doing this for platforms where we haven't otherwise got an implementation. Any port in a storm. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6309: ECPG pre-processor issue
That's great. Thanks for doing this and getting back to us. Andrew Milne On 18/12/11 17:50, Michael Meskes wrote: On Fri, Nov 25, 2011 at 12:51:51PM +, Andrew Milne wrote: The ECPG pre-processor seems to be incorrectly reporting an error when parsing "EXEC SQL AT :cnx DEALLOCATE..." style commands. Thanks for bringing this up. These checks seem to be leftovers from the old code that only emulated prepare statments. I've removed the checks for all versions starting at 8.4. The next release should be fine for you. Michael -- 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 #6346: unsubscribe doesn't work
The following bug has been logged on the website: Bug reference: 6346 Logged by: Marcel Arts Email address: ma...@jambo-software.com PostgreSQL version: Unsupported/Unknown Operating system: unix Description: Hi, I try to unsubscribe but your systen says my email does not exist??!!? your email: unsubscribe pgsql-announce The unsubscribe command did not succeed. No e-mail addresses matching ma...@jambo-software.com are subscribed to the pgsql-announce mailing list. Valid commands processed: 1 0 succeeded, 0 stalled, and 1 failed. Use the following command: sessioninfo c87027392a0481ce78832f58fd11b1bc01c97e63 to see technical information about this session. I receive mails from "pgsql-annou...@postgresql.org" and i don't want theme anymore. gtz, Marcel Arts -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
On 19.12.2011 16:31, Robert Haas wrote: On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote: It probably makes sense to use it on any platform where it's defined. Presumably an implementation provided by the compiler is always going to be at least as good as any magic assembler incantations we can come up with. I agree. How about a patch like this? It uses builtin atomics if available, and falls back to the custom implementations if not. -1. Absent some evidence that gcc's implementations are superior to ours, I think we should not change stuff that works now. That's likely to lead to subtle bugs that are hard to find and perhaps dependent on the exact compiler version used. Ok, we're in disagreement on that then. I don't feel very strongly about it, let's see what others think. One thing that caught my eye: if you use __sync_lock_and_test() to implement S_LOCK(), you really should be using __sync_lock_release() for S_UNLOCK(). Actually, I believe our Itanium (and possibly ARM, too) implementation of S_UNLOCK() is wrong as it is. There is no platform-specific S_UNLOCK() defined for Itanium, so we're using the generic implementation: #if !defined(S_UNLOCK) #define S_UNLOCK(lock) (*((volatile slock_t *) (lock)) = 0) #endif /* S_UNLOCK */ That is not sufficient on platforms with a weak memory model, like Itanium. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
Hi, Craig Now my process is blocked and I have the case in my hands. Do you have something to ask me in order to have more details ? Regards, Andrea -Messaggio originale- Da: Craig Ringer [mailto:ring...@ringerc.id.au] Inviato: sabato 17 dicembre 2011 7.19 A: Andrea Grassi Cc: pgsql-bugs@postgresql.org Oggetto: Re: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function On 16/12/2011 10:10 PM, Andrea Grassi wrote: > The client program and the postgres server are on the same host, client > connects to 127.0.0.1. > In the meantime, my original program blocks (not my example but very probably > the reasons are the same). > > I typed "ps -C testprogramname -o wchan:80=" and the output was only a single > dash ( "-" ). That means it's not waiting in a kernel call right now. Was the program in the hung state you've observed at the time you ran the command? Its output would only be interesting when it's hung. > I searched for the complete stack in /proc/$pid/stack (where $pid) was the > pid of my process but this file doesn't exists !! Why ? Old kernel, maybe? You're running on some kind of enterprise-y distro, so who knows how ancient half the stuff in there is. -- Craig Ringer -- 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 #6347: Reopening bug #6085
The following bug has been logged on the website: Bug reference: 6347 Logged by: Alexander Fortin Email address: alexander.for...@gmail.com PostgreSQL version: 9.1.2 Operating system: Ubuntu 10.04.3 Description: Hi folks. I'm testing 9.1.2 (source compiled) pg_upgrade (upgrading from 8.4.9) and it seems that the problem exposed in bug #6085 is still there. In my case, the only way to make pg_upgrade work is to actually force unix_socket_directory = '/tmp/' for the 8.4.9 cluster. Running in verbose mode Performing Consistency Checks on Old Live Server Checking current, bin, and data directories ok Checking cluster versions ok connection to database failed: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
Heikki Linnakangas writes: > On 19.12.2011 16:31, Robert Haas wrote: >> On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote: >>> I agree. How about a patch like this? It uses builtin atomics if >>> available, and falls back to the custom implementations if not. >> -1. Absent some evidence that gcc's implementations are superior to >> ours, I think we should not change stuff that works now. That's >> likely to lead to subtle bugs that are hard to find and perhaps >> dependent on the exact compiler version used. > Ok, we're in disagreement on that then. I don't feel very strongly about > it, let's see what others think. I agree with Robert. There is no evidence whatsoever that this would be an improvement, and unless somebody cares to provide such evidence, we shouldn't risk changing code that's so full of portability hazards. > Actually, I believe our Itanium (and possibly ARM, too) implementation > of S_UNLOCK() is wrong as it is. Hmm. Anybody got a large itanium box we could play with? If it is wrong, I'd expect it would show up pretty quickly under pgbench or similar. 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
Re: [BUGS] [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
Robert Haas [2011-12-19 9:31 -0500]: > On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote: > >> It probably makes sense to use it on any platform where it's > >> defined. Presumably an implementation provided by the compiler is > >> always going to be at least as good as any magic assembler > >> incantations we can come up with. > > > > I agree. How about a patch like this? It uses builtin atomics if > > available, and falls back to the custom implementations if not. > > -1. Absent some evidence that gcc's implementations are superior to > ours, I think we should not change stuff that works now. That's > likely to lead to subtle bugs that are hard to find and perhaps > dependent on the exact compiler version used. > > But I'm completely cool with doing this for platforms where we haven't > otherwise got an implementation. Any port in a storm. Sure, then the other option is to stuff this at the end of s_lock.h if we don't already have HAS_TEST_AND_SET. This would then mean that we need to remove the armel implementation, as it doesn't really work on anything non-ancient, and the gcc one got some fairly good test coverage by now. I'm happy to work out the patch for this. I'll just wait a bit if there are more comments on this. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
Heikki Linnakangas [2011-12-19 17:09 +0200]: > One thing that caught my eye: if you use __sync_lock_and_test() to > implement S_LOCK(), you really should be using __sync_lock_release() > for S_UNLOCK(). Right, the patch I send does that: #define S_UNLOCK(lock) __sync_lock_release(lock) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
Tom Lane [2011-12-19 10:25 -0500]: > Heikki Linnakangas writes: > > On 19.12.2011 16:31, Robert Haas wrote: > >> On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote: > >>> I agree. How about a patch like this? It uses builtin atomics if > >>> available, and falls back to the custom implementations if not. > > >> -1. Absent some evidence that gcc's implementations are superior to > >> ours, I think we should not change stuff that works now. That's > >> likely to lead to subtle bugs that are hard to find and perhaps > >> dependent on the exact compiler version used. > > > Ok, we're in disagreement on that then. I don't feel very strongly about > > it, let's see what others think. > > I agree with Robert. There is no evidence whatsoever that this would > be an improvement, and unless somebody cares to provide such evidence, > we shouldn't risk changing code that's so full of portability hazards. OK, with you and Robert preferring this as a fallback instead of a preferred way, and with Heikki's "I don't care much", I'll rework the patch. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
On 19.12.2011 17:39, Martin Pitt wrote: Heikki Linnakangas [2011-12-19 17:09 +0200]: One thing that caught my eye: if you use __sync_lock_and_test() to implement S_LOCK(), you really should be using __sync_lock_release() for S_UNLOCK(). Right, the patch I send does that: #define S_UNLOCK(lock) __sync_lock_release(lock) Oh, I'm blind... Can you comment on or test whether the existing TAS implementation is broken on ARM, because the existing S_UNLOCK() on ARM doesn't act as a memory barrier? If we're going to keep the existing snippet of inline assembly for those variants of ARM where it works, we need to either fix S_UNLOCK or convince ourselves that it's not broken. I'll take a closer look at the same on Itanium. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
On 19.12.2011 17:25, Tom Lane wrote: Heikki Linnakangas writes: On 19.12.2011 16:31, Robert Haas wrote: Actually, I believe our Itanium (and possibly ARM, too) implementation of S_UNLOCK() is wrong as it is. Hmm. Anybody got a large itanium box we could play with? If it is wrong, I'd expect it would show up pretty quickly under pgbench or similar. We've been running pgbench heavily recently in the company on large HP Itanium boxes with 32 and 64 cores, and haven't seen any issues. I'm not sure how it would manifest itself, though. It's also possible that while it's a genuine bug at the source level, it happens to be masked by some compiler decisions. It sure looks wrong. I'll try to construct a self-contained test program to exercise that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] [PATCH v2] Use CC atomic builtins as a fallback
Robert Haas [2011-12-19 9:31 -0500]:
> -1. Absent some evidence that gcc's implementations are superior to
> ours, I think we should not change stuff that works now. That's
> likely to lead to subtle bugs that are hard to find and perhaps
> dependent on the exact compiler version used.
>
> But I'm completely cool with doing this for platforms where we haven't
> otherwise got an implementation. Any port in a storm.
The updated patch only uses the gcc builtins if there is no explicit
implementation, but drops the arm one as this doesn't work on ARMv7
and newer, as stated in the original mail.
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, if available (http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html). Remove the custom implementation for arm as it does not work with recent hardware (like -mthumb2).
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 2011-12-19 16:54:00.619535943 +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 2011-12-19 16:54:00.635535943 +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 2011-12-19 16:54:00.639535943 +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 to 1 if you have the `class' function. */
#undef HAVE_CLASS
Index: postgresql-9.1-9.1.2/src/include/storage/s_lock.h
===
--- postgresql-9.1-9.1.2.orig/src/include/storage/s_lock.h 2011-12-01 22:47:20.0 +0100
+++ postgresql-9.1-9.1.2/src/include/storage/s_lock.h 2011-12-19 16:56
Re: [BUGS] BUG #6346: unsubscribe doesn't work
Excerpts from marts's message of lun dic 19 10:53:37 -0300 2011: > Hi, > > I try to unsubscribe but your systen says my email does not exist??!!? > > your email: > unsubscribe pgsql-announce > The unsubscribe command did not succeed. > > No e-mail addresses matching > ma...@jambo-software.com > are subscribed to the pgsql-announce mailing list. That's correct; we don't have any "marts" address on file. We have one mar...@jambo-software.com however; you may want to unsubscribe that one instead. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote: > Actually, I believe our Itanium (and possibly ARM, too) implementation > of S_UNLOCK() is wrong as it is. There is no platform-specific > S_UNLOCK() defined for Itanium, so we're using the generic > implementation: > > #if !defined(S_UNLOCK) > #define S_UNLOCK(lock)(*((volatile slock_t *) (lock)) = 0) > #endif /* S_UNLOCK */ > > That is not sufficient on platforms with a weak memory model, like Itanium. Other processors may observe the lock as held after its release, but there's no correctness problem. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
Noah Misch writes: > On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote: >> That is not sufficient on platforms with a weak memory model, like Itanium. > Other processors may observe the lock as held after its release, but there's > no > correctness problem. How weak is the memory model, exactly? A correctness problem would ensue if out-of-order stores are possible, ie other processors could observe the lock being freed (and then acquire it) before seeing changes to shared variables that had been made while holding the lock. I'm a little dubious that this applies to Itanium, because I don't see any memory fence instruction in the TAS macro. If we needed one in S_UNLOCK I'd rather expect there to be one in TAS as well. 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] Re: [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
On 19.12.2011 22:03, Noah Misch wrote: On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote: Actually, I believe our Itanium (and possibly ARM, too) implementation of S_UNLOCK() is wrong as it is. There is no platform-specific S_UNLOCK() defined for Itanium, so we're using the generic implementation: #if !defined(S_UNLOCK) #define S_UNLOCK(lock) (*((volatile slock_t *) (lock)) = 0) #endif /* S_UNLOCK */ That is not sufficient on platforms with a weak memory model, like Itanium. Other processors may observe the lock as held after its release, but there's no correctness problem. I thought it would also be legal for a store to become visible to other processors, *after* the releasing of the lock. Which would be bad. For example, if you have: volatile bool *shared = ... SpinLockAcquire(lock); shared->variable = true; SpinLockRelease(lock); more code The macro-expanded code would look like: lock shared->variable = true; (*((volatile slock_t *) (lock)) = 0; more code I believe on an architecture with a weak memory model, like Itanium, there's no guarantee that the assignments will happen in that order. The lock might appear as released *before* the variable is set. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
On 19.12.2011 22:12, Tom Lane wrote:
Noah Misch writes:
On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote:
That is not sufficient on platforms with a weak memory model, like Itanium.
Other processors may observe the lock as held after its release, but there's no
correctness problem.
How weak is the memory model, exactly?
A correctness problem would ensue if out-of-order stores are possible,
ie other processors could observe the lock being freed (and then acquire
it) before seeing changes to shared variables that had been made while
holding the lock.
I'm a little dubious that this applies to Itanium, because I don't see
any memory fence instruction in the TAS macro. If we needed one in
S_UNLOCK I'd rather expect there to be one in TAS as well.
There's a pretty good manual called "Implementing Spinlocks on Itanium
and PA-RISC" from HP at:
http://h21007.www2.hp.com/portal/download/files/unprot/itanium/spinlocks.pdf.
It says, in section "3.2.1 Try to get a spinlock":
> Note also, that the ‘xchg’ instruction always
> has the ‘acquire’ semantics, so it enforces the correct memory ordering.
But the current implementation seems to be safe, anyway. In section
"3.2.3 Freeing a spinlock", that manual says:
> Note, that a simple assignment statement into a volatile variable
will not work, as we are
> assuming that the +Ovolatile=__unordered compile option is being used.
So +Ovolatile=__unordered would allow the kind of optimization that I
thought was possible, and we would have a problem if we used it. But the
default is more conservative, and a simple assignment does work.
I compiled the attached test program on an HP Itanium box, using the
same flags you get from PostgreSQL's configure on that box. The relevant
assembler output is:
xchg4 r14 = [r15], r14 // M [slocktest.c: 66/3]
//file/line/col slocktest.c/67/3
ld1.acq r16 = [r11]// M [slocktest.c: 67/3]
nop.i 0 // I
//file/line/col slocktest.c/68/3
st1.rel [r11] = r10 ;; // M [slocktest.c: 68/3]
//file/line/col slocktest.c/69/3
st4.rel [r15] = r0 // M [slocktest.c: 69/3]
//file/line/col slocktest.c/70/1
The trick I missed is that the compiler attaches .rel to all the stores
and .acq to all the loads through a volatile pointer. gcc seems to do
the same. So we're safe.
It would be interesting to test whether using +Ovolatile=__unordered
would make a difference to performance. Tacking those memory fence
modifiers to all the volatile loads and stores might be expensive.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
#include
#if defined(__GNUC__) || defined(__INTEL_COMPILER)
#if defined(__ia64__) || defined(__ia64) /* Intel Itanium */
#define HAS_TEST_AND_SET
typedef unsigned int slock_t;
#define TAS(lock) tas(lock)
/* On IA64, it's a win to use a non-locking test before the xchg proper */
#define TAS_SPIN(lock) (*(lock) ? 1 : TAS(lock))
#ifndef __INTEL_COMPILER
static __inline__ int
tas(volatile slock_t *lock)
{
long int ret;
__asm__ __volatile__(
" xchg4 %0=%1,%2 \n"
: "=r"(ret), "+m"(*lock)
: "r"(1)
: "memory");
return (int) ret;
}
#else /* __INTEL_COMPILER */
static __inline__ int
tas(volatile slock_t *lock)
{
int ret;
ret = _InterlockedExchange(lock,1); /* this is a xchg asm macro */
return ret;
}
#endif /* __INTEL_COMPILER */
#endif /* __ia64__ || __ia64 */
#endif /* defined(__GNUC__) || defined(__INTEL_COMPILER) */
#if defined(__hpux) && defined(__ia64) && !defined(__GNUC__)
#define HAS_TEST_AND_SET
typedef unsigned int slock_t;
#include
#define TAS(lock) _Asm_xchg(_SZ_W, lock, 1, _LDHINT_NONE)
/* On IA64, it's a win to use a non-locking test before the xchg proper */
#define TAS_SPIN(lock) (*(lock) ? 1 : TAS(lock))
#endif /* HPUX on IA64, non gcc */
slock_t lock;
char shared2;
int main(int argc, char **argv)
{
volatile char *p = &shared2;
char local;
TAS(&lock);
local = *p;
*p = 123;
*((volatile slock_t *) &lock) = 0;
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: [PATCH] Use CC atomic builtins if available [was: Re: TAS patch for building on armel/armhf thumb]
On Mon, Dec 19, 2011 at 11:25:06PM +0200, Heikki Linnakangas wrote: > I compiled the attached test program on an HP Itanium box, using the > same flags you get from PostgreSQL's configure on that box. The relevant > assembler output is: > > xchg4 r14 = [r15], r14 // M [slocktest.c: 66/3] > //file/line/col slocktest.c/67/3 > ld1.acq r16 = [r11]// M [slocktest.c: 67/3] > nop.i 0 // I > //file/line/col slocktest.c/68/3 > st1.rel [r11] = r10 ;; // M [slocktest.c: 68/3] > //file/line/col slocktest.c/69/3 > st4.rel [r15] = r0 // M [slocktest.c: 69/3] > //file/line/col slocktest.c/70/1 > > > The trick I missed is that the compiler attaches .rel to all the stores > and .acq to all the loads through a volatile pointer. gcc seems to do > the same. So we're safe. The Intel compiler appears not to follow this convention: http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/copts/ccpp_options/option_qserialize-volatile.htm If you have that compiler installed, could you see which opcode it generates? Thanks, nm -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
