Re: [HACKERS] Thread safety and libxml2
On Mon, Apr 19, 2010 at 10:52 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Feb 18, 2010 at 8:41 PM, Bruce Momjian br...@momjian.us wrote: Peter Eisentraut wrote: On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote: Basically, configure failed on their OpenBSD system because thread safety is on but the libxml2 wasn't compiled with threaded support: http://xmlsoft.org/threads.html Disabling either feature (no --with-libxml or --disable-thread-safety) gives a working build. This could perhaps be fixed by excluding libxml when running the thread test. The thread result is only used in the client libraries and libxml is only used in the backend, so those two shouldn't meet each other in practice. The attached patch removes -lxml2 from the link line of the thread test program. Comments? Can anyone test this fixes the OpenBSD problem? Can someone take the time to test this whether this patch fixes the problem? This is on the list of open items for PG 9.0, but considering that there's been a proposed patch available for almost two months and no responses to this thread, it may be time to conclude that nobody cares very much - in which case we can either remove this item or relocate it to the TODO list. Since no one has responded to this, I'm moving this to the section of the open items list called long-term issues: These items are not 9.0-specific. They should be fixed eventually, but not for now. I am inclined to think this isn't worth adding to the main TODO list. If someone complains about it again, we can ask them to test the patch. If not, I don't see much point in investing any more time in it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Thread safety and libxml2
On Thu, Feb 18, 2010 at 8:41 PM, Bruce Momjian br...@momjian.us wrote: Peter Eisentraut wrote: On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote: Basically, configure failed on their OpenBSD system because thread safety is on but the libxml2 wasn't compiled with threaded support: http://xmlsoft.org/threads.html Disabling either feature (no --with-libxml or --disable-thread-safety) gives a working build. This could perhaps be fixed by excluding libxml when running the thread test. The thread result is only used in the client libraries and libxml is only used in the backend, so those two shouldn't meet each other in practice. The attached patch removes -lxml2 from the link line of the thread test program. Comments? Can anyone test this fixes the OpenBSD problem? Can someone take the time to test this whether this patch fixes the problem? This is on the list of open items for PG 9.0, but considering that there's been a proposed patch available for almost two months and no responses to this thread, it may be time to conclude that nobody cares very much - in which case we can either remove this item or relocate it to the TODO list. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Thread safety and libxml2
Peter Eisentraut wrote:
On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
Basically, configure failed on their OpenBSD system because thread
safety is on but the libxml2 wasn't compiled with threaded support:
http://xmlsoft.org/threads.html
Disabling either feature (no --with-libxml or --disable-thread-safety)
gives a working build.
This could perhaps be fixed by excluding libxml when running the thread
test. The thread result is only used in the client libraries and libxml
is only used in the backend, so those two shouldn't meet each other in
practice.
The attached patch removes -lxml2 from the link line of the thread
test program. Comments? Can anyone test this fixes the OpenBSD
problem?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: configure
===
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.671
diff -c -c -r1.671 configure
*** configure 17 Feb 2010 04:19:36 - 1.671
--- configure 19 Feb 2010 00:40:05 -
***
*** 28593,28599
_CFLAGS=$CFLAGS
_LIBS=$LIBS
CFLAGS=$CFLAGS $PTHREAD_CFLAGS -DIN_CONFIGURE
! LIBS=$LIBS $PTHREAD_LIBS
if test $cross_compiling = yes; then
{ $as_echo $as_me:$LINENO: result: maybe 5
$as_echo maybe 6; }
--- 28593,28601
_CFLAGS=$CFLAGS
_LIBS=$LIBS
CFLAGS=$CFLAGS $PTHREAD_CFLAGS -DIN_CONFIGURE
! # On OpenBSD, libxml2 is not thread-safe, but it is not used in the backend
! # 2010-02-18
! LIBS=`echo $LIBS | sed 's/-lxml2 //'`$PTHREAD_LIBS
if test $cross_compiling = yes; then
{ $as_echo $as_me:$LINENO: result: maybe 5
$as_echo maybe 6; }
Index: configure.in
===
RCS file: /cvsroot/pgsql/configure.in,v
retrieving revision 1.623
diff -c -c -r1.623 configure.in
*** configure.in 17 Feb 2010 04:19:37 - 1.623
--- configure.in 19 Feb 2010 00:40:10 -
***
*** 1746,1752
_CFLAGS=$CFLAGS
_LIBS=$LIBS
CFLAGS=$CFLAGS $PTHREAD_CFLAGS -DIN_CONFIGURE
! LIBS=$LIBS $PTHREAD_LIBS
AC_TRY_RUN([#include $srcdir/src/test/thread/thread_test.c],
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
--- 1746,1754
_CFLAGS=$CFLAGS
_LIBS=$LIBS
CFLAGS=$CFLAGS $PTHREAD_CFLAGS -DIN_CONFIGURE
! # On OpenBSD, libxml2 is not thread-safe, but it is not used in the backend
! # 2010-02-18
! LIBS=`echo $LIBS | sed 's/-lxml2 //'`$PTHREAD_LIBS
AC_TRY_RUN([#include $srcdir/src/test/thread/thread_test.c],
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Thread safety and libxml2
On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote: Basically, configure failed on their OpenBSD system because thread safety is on but the libxml2 wasn't compiled with threaded support: http://xmlsoft.org/threads.html Disabling either feature (no --with-libxml or --disable-thread-safety) gives a working build. This could perhaps be fixed by excluding libxml when running the thread test. The thread result is only used in the client libraries and libxml is only used in the backend, so those two shouldn't meet each other in practice. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Thread safety and libxml2
We got an interesting report on the testers list today: http://archives.postgresql.org/pgsql-testers/2009-12/msg0.php Basically, configure failed on their OpenBSD system because thread safety is on but the libxml2 wasn't compiled with threaded support: http://xmlsoft.org/threads.html Disabling either feature (no --with-libxml or --disable-thread-safety) gives a working build. I wonder if it's worthwhile to document this coupling between thread safety and libxml2 in either http://developer.postgresql.org/pgdocs/postgres/install-procedure.html or even the release notes. It seems quite likely to bite someone else again the future. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
Greg Stark gsst...@mit.edu writes: On Fri, Dec 11, 2009 at 6:08 PM, Tom Lane t...@sss.pgh.pa.us wrote: I'll commit a fix for that shortly, but this reminds me once again that the EvalPlanQual logic is desperately under-tested in our normal regression testing. We really need some kind of testing infrastructure that would let us exercise concurrent-update cases a bit more than not at all. If i went back and cleaned up the parallel psql patch we would be able to write tests which tested basic concurrent functionality such as transactions blocking when they're supposed to. But that wouldn't catch something like this I don't think, not unless it got triggered pretty reliably by a simple evalplanqual recheck. It would have been caught if anyone had tried an EvalPlanQual'd update on a table with one of the unchanged columns being a non-null pass-by-ref value. Now it's certainly possible that a set of regression tests would by chance fail to exercise that case --- but IMO the real problem right now is we aren't even trying to exercise EvalPlanQual; we're actively avoiding it because the current test infrastructure can't ensure deterministic results if any such situation arises. But my recollection of the parallel psql patch discussion is that it was rejected because nobody felt comfortable with the API design. Do we have any better ideas in that department yet? 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
Re: [HACKERS] thread safety on clients
Tom Lane wrote: But my recollection of the parallel psql patch discussion is that it was rejected because nobody felt comfortable with the API design. Do we have any better ideas in that department yet? It wasn't rejected AFAICT. A finalized API with which there was (almost?) no dissent was posted by you, after a design/path from Greg Stark. The problem is that nobody stepped up to implementing that spec. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
On Fri, Dec 11, 2009 at 6:08 PM, Tom Lane t...@sss.pgh.pa.us wrote: I wrote: I'll commit a fix for that shortly, but this reminds me once again that the EvalPlanQual logic is desperately under-tested in our normal regression testing. We really need some kind of testing infrastructure that would let us exercise concurrent-update cases a bit more than not at all. If i went back and cleaned up the parallel psql patch we would be able to write tests which tested basic concurrent functionality such as transactions blocking when they're supposed to. But that wouldn't catch something like this I don't think, not unless it got triggered pretty reliably by a simple evalplanqual recheck. I'm inclined to think this is bad, and we should fix pgbench to re-randomize after forking. If we don't, we'll have synchronized behavior on some platforms and not others, which doesn't seem like a good idea. On the other hand, if you did want that type of behavior, it's hard to see how you'd get it. Is it worth trying to provide that as a (probably non-default) mode in pgbench? If so, how would you do it on threaded platforms? Well it's pretty useless for benchmarking unless someone comes up with a different plan for resolving these kinds of conflicts and we wanted to compare the costs. But it's clearly something we should do for testing for precisely this kind of bug. EvalPlanQual could trigger all kinds of bugs throughout the executor and it would be worth having something like this to check for them. I believe it's possible to give at least one of the random number generating apis a preallocated buffer for it to use to store the generator state, that could easily be per-thread state along with the connection and other state. I'm not sure which api that was and whether it's as portable or as good a generator as what we're using now though. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
Jaime Casanova wrote: On Thu, Dec 10, 2009 at 11:33 PM, Jaime Casanova jcasa...@systemguards.com.ec wrote: On Thu, Dec 10, 2009 at 11:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: My bet is that the real problem was a build inconsistency in the backend. Does make distclean and rebuild make it go away? actually it was a clean build just after a cvs co (not an updated tree), i build the binaries and installed it in just created directory... i will try again now with the patch Bruce just committed the problem has gone Yes, but what if you test with the broken pgbench? As Tom says, it should not be able to crash the backend no matter what it does. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
Alvaro Herrera alvhe...@commandprompt.com writes: Yes, but what if you test with the broken pgbench? As Tom says, it should not be able to crash the backend no matter what it does. The crash is real --- I've replicated it here. Still trying to figure out what is the real cause. 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
Re: [HACKERS] thread safety on clients
On 12/11/09, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Yes, but what if you test with the broken pgbench? As Tom says, it should not be able to crash the backend no matter what it does. The crash is real --- I've replicated it here. Still trying to figure out what is the real cause. Several threads writing to single connection? -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
I wrote: The crash is real --- I've replicated it here. Still trying to figure out what is the real cause. Okay, I've sussed it. The crash itself is due to a memory management mistake in the recently-rewritten EvalPlanQual code (pfree'ing a tuple that we still have live Datum references to). The reason the broken pgbench is able to trigger it is that it generates concurrent updates for the same row in pgbench_accounts with much higher frequency than normal. This forces the backends through the EvalPlanQual code, which is broken and crashes. QED. I'll commit a fix for that shortly, but this reminds me once again that the EvalPlanQual logic is desperately under-tested in our normal regression testing. We really need some kind of testing infrastructure that would let us exercise concurrent-update cases a bit more than not at all. Also, the reason why Bruce's mistake exposed this is interesting. Omitting the #define for ENABLE_THREAD_SAFETY does not actually break pgbench -j at all -- it has a fallback strategy that uses multiple subprocesses instead of multiple threads. However, it has only one srandom() call, which occurs in the parent process before forking. This means that the subprocesses all start with the same random number state, which means they generate the same sequence of random account IDs to update, which is why the probability of an update collision requiring EvalPlanQual resolution is so high, especially at the start of the run (and the crash does happen pretty much immediately after starting pgbench). I'm inclined to think this is bad, and we should fix pgbench to re-randomize after forking. If we don't, we'll have synchronized behavior on some platforms and not others, which doesn't seem like a good idea. On the other hand, if you did want that type of behavior, it's hard to see how you'd get it. Is it worth trying to provide that as a (probably non-default) mode in pgbench? If so, how would you do it on threaded platforms? 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
Re: [HACKERS] thread safety on clients
Tom Lane wrote: Also, the reason why Bruce's mistake exposed this is interesting. Omitting the #define for ENABLE_THREAD_SAFETY does not actually break pgbench -j at all -- it has a fallback strategy that uses multiple subprocesses instead of multiple threads. However, it has only one srandom() call, which occurs in the parent process before forking. This means that the subprocesses all start with the same random number state, which means they generate the same sequence of random account IDs to update We just got that as a bug report the other day too, with suggested fixes: http://archives.postgresql.org/pgsql-hackers/2009-12/msg00841.php I'm inclined to think this is bad, and we should fix pgbench to re-randomize after forking. If we don't, we'll have synchronized behavior on some platforms and not others, which doesn't seem like a good idea. On the other hand, if you did want that type of behavior, it's hard to see how you'd get it. Is it worth trying to provide that as a (probably non-default) mode in pgbench? If so, how would you do it on threaded platforms? It sounds like random pgbench run for a while would certainly expose the same thing you're concerned about eventually. I doubt it's worth the trouble to codify a bug just because it found another bug (it's hard enough to maintain code that only has to work right). If we want to stress this behavior, it would be easier to just test with a a bunch of clients going through a scale=1 database and use enough transactions to make update collisions likely. I'm working on a guide to stress testing new alpha builds with pgbench that will be ready in time for alpha3. I could easily add that as one of the suggested tests to run if you're concerned about getting more test coverage of that code path. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
Greg Smith g...@2ndquadrant.com writes: It sounds like random pgbench run for a while would certainly expose the same thing you're concerned about eventually. Yeah. Actually the odd thing about it is that the crash seemed to invariably be on conflicting pgbench_accounts updates, which is a fairly low-contention table in this test design (but the bug turned it into high-contention). What I would have expected is crashes on the very similar updates to pgbench_branches, which is designed to be high-contention. It might be that there is some other effect going on here that explains why that wasn't happening. Need to go back and look more closely. 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
Re: [HACKERS] thread safety on clients
I wrote: ... What I would have expected is crashes on the very similar updates to pgbench_branches, which is designed to be high-contention. It might be that there is some other effect going on here that explains why that wasn't happening. Need to go back and look more closely. ... and the answer to that is that pgbench_branches isn't subject to the bug, because its only pass-by-reference column happens to be filled with all NULLs by the initialization step, unlike the accounts filler column which happens to be filled with non-null strings. Null values mean no dangling pointers and no chance for a memory management issue. So you could have run this all day and never seen a crash on pgbench_branches updates. (If you manually set the filler column non-null before starting a run, the unpatched code crashes instantly, even with a non-bollixed pgbench.) So, nothing to see here except lack of test coverage, move along. 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
Re: [HACKERS] thread safety on clients
On ons, 2009-12-09 at 14:02 -0500, Jaime Casanova wrote: Hi, I compiled current HEAD and trying to use pgbench, i initialized a test database this way: bin/pgbench -i -F80 -s100 test and then run with this options: bin/pgbench -c 50 -j 5 -l -t 20 test and get this crash: starting vacuum...end. TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) Client 0 aborted in state 8. Probably the backend died while processing. LOG: server process (PID 30713) was terminated by signal 6: Aborted TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) Client 8 aborted in state 8. Probably the backend died while processing. LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. if i remove the -j option then it runs without a problem Possibly related to the incomplete removal of the enable-thread-safety option that I just posted about. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
Peter Eisentraut wrote: starting vacuum...end. TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) Client 0 aborted in state 8. Probably the backend died while processing. LOG: server process (PID 30713) was terminated by signal 6: Aborted TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) Client 8 aborted in state 8. Probably the backend died while processing. LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. if i remove the -j option then it runs without a problem Possibly related to the incomplete removal of the enable-thread-safety option that I just posted about. I thought about that but I can't figure out how that would affect pgbench. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
Bruce Momjian wrote: Peter Eisentraut wrote: if i remove the -j option then it runs without a problem Possibly related to the incomplete removal of the enable-thread-safety option that I just posted about. I thought about that but I can't figure out how that would affect pgbench. The -j option is the recent addition to pgbench that causes it to launch multiple client threads when enabled, each handling a subset of the transactions. There's blocks of codes in pgbench.c now that depend on having sane values for thread safety in libpq. That it may be detecting the wrong thing and operating in an unsafe way after the recent change is what Peter's suggesting. This is good, actually, because I don't think we had many client-side thread-safety tests floating around to catch problems in this area before. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com
Re: [HACKERS] thread safety on clients
Greg Smith wrote: Bruce Momjian wrote: Peter Eisentraut wrote: if i remove the -j option then it runs without a problem Possibly related to the incomplete removal of the enable-thread-safety option that I just posted about. I thought about that but I can't figure out how that would affect pgbench. The -j option is the recent addition to pgbench that causes it to launch multiple client threads when enabled, each handling a subset of the transactions. There's blocks of codes in pgbench.c now that depend on having sane values for thread safety in libpq. That it may be detecting the wrong thing and operating in an unsafe way after the recent change is what Peter's suggesting. This is good, actually, because I don't think we had many client-side thread-safety tests floating around to catch problems in this area before. I can reproduce the crash here so I can see if I can find the cause. However, the failure is happening in the _server_. Threading is unrelated to the server itself, only the client. I suppose the first test for me will be to test CVS before the thread change was made. The failure is in heap_fill_tuple(), and I am unclear how that assert could be getting triggered: CONTEXT: automatic analyze of table test.public.pgbench_accounts TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) LOG: server process (PID 6076) was terminated by signal 6: Abort trap LOG: terminating any other active server processes -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
Bruce Momjian wrote: Greg Smith wrote: Bruce Momjian wrote: Peter Eisentraut wrote: if i remove the -j option then it runs without a problem Possibly related to the incomplete removal of the enable-thread-safety option that I just posted about. I thought about that but I can't figure out how that would affect pgbench. The -j option is the recent addition to pgbench that causes it to launch multiple client threads when enabled, each handling a subset of the transactions. There's blocks of codes in pgbench.c now that depend on having sane values for thread safety in libpq. That it may be detecting the wrong thing and operating in an unsafe way after the recent change is what Peter's suggesting. This is good, actually, because I don't think we had many client-side thread-safety tests floating around to catch problems in this area before. I can reproduce the crash here so I can see if I can find the cause. However, the failure is happening in the _server_. Threading is unrelated to the server itself, only the client. I suppose the first test for me will be to test CVS before the thread change was made. The failure is in heap_fill_tuple(), and I am unclear how that assert could be getting triggered: CONTEXT: automatic analyze of table test.public.pgbench_accounts TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) LOG: server process (PID 6076) was terminated by signal 6: Abort trap LOG: terminating any other active server processes OK, turns out I did break threading by not defining ENABLE_THREAD_SAFETY in configure. I have applied a patch to CVS to fix this. However, the larger question is how did I crash a backend by not defining this? I guess it is possible for a client to crash the server by having a misconfigured client --- I wasn't aware of that. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
Greg Smith g...@2ndquadrant.com writes: The -j option is the recent addition to pgbench that causes it to launch multiple client threads when enabled, each handling a subset of the transactions. There's blocks of codes in pgbench.c now that depend on having sane values for thread safety in libpq. That it may be detecting the wrong thing and operating in an unsafe way after the recent change is what Peter's suggesting. This is good, actually, because I don't think we had many client-side thread-safety tests floating around to catch problems in this area before. The report showed an assert inside the backend. It really doesn't matter *how* broken pgbench might be, it should not be able to cause that. My bet is that the real problem was a build inconsistency in the backend. Does make distclean and rebuild make it go away? 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
Re: [HACKERS] thread safety on clients
On Thu, Dec 10, 2009 at 11:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: My bet is that the real problem was a build inconsistency in the backend. Does make distclean and rebuild make it go away? actually it was a clean build just after a cvs co (not an updated tree), i build the binaries and installed it in just created directory... i will try again now with the patch Bruce just committed -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety on clients
On Thu, Dec 10, 2009 at 11:33 PM, Jaime Casanova jcasa...@systemguards.com.ec wrote: On Thu, Dec 10, 2009 at 11:22 PM, Tom Lane t...@sss.pgh.pa.us wrote: My bet is that the real problem was a build inconsistency in the backend. Does make distclean and rebuild make it go away? actually it was a clean build just after a cvs co (not an updated tree), i build the binaries and installed it in just created directory... i will try again now with the patch Bruce just committed the problem has gone -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] thread safety on clients
Hi, I compiled current HEAD and trying to use pgbench, i initialized a test database this way: bin/pgbench -i -F80 -s100 test and then run with this options: bin/pgbench -c 50 -j 5 -l -t 20 test and get this crash: starting vacuum...end. TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) Client 0 aborted in state 8. Probably the backend died while processing. LOG: server process (PID 30713) was terminated by signal 6: Aborted TRAP: FailedAssertion(!((data - start) == data_size), File: heaptuple.c, Line: 255) Client 8 aborted in state 8. Probably the backend died while processing. LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. if i remove the -j option then it runs without a problem -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Thread safety
Magnus Hagander wrote: Can someone remind me why we have --enable-thread-safety? As opposed to it being default and having --disable-thread-safety. I don't have any numbers or a roster to support this, but I suppose that thread-safety is not supported on some platforms. So either we'd have to have diverging defaults or annoy those unsupported platforms with a mandatory switch. The situation is quite similar in my view to the integer datetimes switch: we need a very high level of platform support before turning this on by default. (I suppose there was initially also some general uncertainty about the maturity of thread things, but I think we can consider that satisfied by now.) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Thread safety
Peter Eisentraut wrote: Magnus Hagander wrote: Can someone remind me why we have --enable-thread-safety? As opposed to it being default and having --disable-thread-safety. I don't have any numbers or a roster to support this, but I suppose that thread-safety is not supported on some platforms. So either we'd have to have diverging defaults or annoy those unsupported platforms with a mandatory switch. We could try switching it for a day and see what happens to the buildfarm ... that would give us an idea of how many platforms are not prepared. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Thread safety
On 27 nov 2008, at 13.00, Alvaro Herrera [EMAIL PROTECTED] wrote: Peter Eisentraut wrote: Magnus Hagander wrote: Can someone remind me why we have --enable-thread-safety? As opposed to it being default and having --disable-thread-safety. I don't have any numbers or a roster to support this, but I suppose that thread-safety is not supported on some platforms. So either we'd have to have diverging defaults or annoy those unsupported platforms with a mandatory switch. We could try switching it for a day and see what happens to the buildfarm ... that would give us an idea of how many platforms are not prepared. +1. It would be very good to have it ok by default if we cab, and that seems luke a good way to see if it's reasonable... /Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Thread safety
Magnus Hagander wrote: On 27 nov 2008, at 13.00, Alvaro Herrera [EMAIL PROTECTED] wrote: Peter Eisentraut wrote: Magnus Hagander wrote: Can someone remind me why we have --enable-thread-safety? As opposed to it being default and having --disable-thread-safety. I don't have any numbers or a roster to support this, but I suppose that thread-safety is not supported on some platforms. So either we'd have to have diverging defaults or annoy those unsupported platforms with a mandatory switch. We could try switching it for a day and see what happens to the buildfarm ... that would give us an idea of how many platforms are not prepared. +1. It would be very good to have it ok by default if we cab, and that seems luke a good way to see if it's reasonable... /Magnus It would probably be useful to nail down the supported platforms, have a list somewhere of the oldest ones: oldest solaris, hpux, irix, aix, sco, etc... I ran into a few --enable-thread-safety problems, Magnus fixed the cygwin build already. hpux 10.20 and solaris 2.5.1 were both broken. Sounds like there is no interest in supporting hpux 10.20, not sure about solaris 2.5.1 realeased in 1996. I only discovered this trying to build libpqtypes, which requires libpq, on our internal build farm. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Thread safety
Andrew Chernow napsal(a): It would probably be useful to nail down the supported platforms, have a list somewhere of the oldest ones: oldest solaris, hpux, irix, aix, sco, etc... I ran into a few --enable-thread-safety problems, Magnus fixed the cygwin build already. hpux 10.20 and solaris 2.5.1 were both broken. Sounds like there is no interest in supporting hpux 10.20, not sure about solaris 2.5.1 realeased in 1996. I don't think so that there is interest to fix it for solaris 2.5.1. Everything older than Solaris 8 is not officially supported (exclude timezone updates which are available for old systems) and Solaris 8 is in EOL mode. Anyway solaris 2.5.1 runs only on old HW and I don't see any benefit to run new PostgreSQL version on hardware with small harddisk and memory. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Thread safety
Can someone remind me why we have --enable-thread-safety? As opposed to it being default and having --disable-thread-safety. /Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] thread safety tests
Jan Wieck wrote:
I looked over the code and the only place getpwuid_r (through
pqGetpwuid) is used is in libpq to look up the default username based on
the euid for the connection to the backend. Unfortunately, I can't find
any other way to do such a lookup in a thread-safe manner unless we do a
system() or lock/read /etc/passwd ourselves, both of which are ugly.
I can't imagine how some OS's cannot give us a thread-safe way to do
this.
When FreeBSD can't enable threads in 7.5, folks are going to be upset.
In 7.4 we allowed it by having our own C code lock/copy the passwd
structure, but someone pointed out that calls to getpwuid() in other
places in the client code don't have such locking, so it would not work,
so it was removed for 7.5.
I disagree that all or nothing is a good strategy. What you have changed
this to is to deny using PostgreSQL from multithreaded applications on
platforms that have no getpwuid_r() altogether, if their platform
happens to require any thread special compiler options for libpq to work
in general.
Take Slony as an example. It is multithreaded, and we aren't happy that
we have to guard the pg_connect() call with a mutex against multiple
concurrent calls. But since our connections are of long living nature
this is no problem. And nowhere else in the entire code is any call to
getpwuid() or anything else. So we have the situation under control. But
I really don't want to tell people in the build instructions that they
have to edit libpq's Makefile because PostgreSQL's ./configure script is
too restrictive.
OK, I have added a configure option --enable-thread-safety-force that
compiles with thread safety even if the OS tests fail. I have not
mentioned this in the SGML docs but mention the option in configure
--help and when you get a thread test failure with
--enable-thread-safety.
Patch attached and applied.
And just to make your day, your tests for thread safety are incomplete.
The reason why we use a mutex now on all platforms, thread safe or not,
is because in the event you have a kerberos lib available (which is not
thread safe), pg_connect() can crash wether you use kerberos or not. So
I think when compiling for --enable-thread-safe we should disable
kerberos in libpq, right?
We have libpq locking for kerberos in CVS.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: configure
===
RCS file: /cvsroot/pgsql-server/configure,v
retrieving revision 1.376
diff -c -c -r1.376 configure
*** configure 24 Jun 2004 18:55:17 - 1.376
--- configure 10 Jul 2004 01:08:16 -
***
*** 846,851
--- 846,852
--enable-depend turn on automatic dependency tracking
--enable-cassertenable assertion checks (for debugging)
--enable-thread-safety make client libraries thread-safe
+ --enable-thread-safety-force force thread-safety in spite of thread test failure
--disable-largefile omit support for large files
Optional Packages:
***
*** 2937,2947
case $enableval in
yes)
!
! cat confdefs.h \_ACEOF
! #define ENABLE_THREAD_SAFETY 1
! _ACEOF
!
;;
no)
:
--- 2938,2944
case $enableval in
yes)
! :
;;
no)
:
***
*** 2958,2963
--- 2955,2994
fi;
+
+
+ # Check whether --enable-thread-safety-force or --disable-thread-safety-force was
given.
+ if test ${enable_thread_safety_force+set} = set; then
+ enableval=$enable_thread_safety_force
+
+ case $enableval in
+ yes)
+ :
+ ;;
+ no)
+ :
+ ;;
+ *)
+ { { echo $as_me:$LINENO: error: no argument expected for
--enable-thread-safety-force option 5
+ echo $as_me: error: no argument expected for --enable-thread-safety-force option
2;}
+{ (exit 1); exit 1; }; }
+ ;;
+ esac
+
+ else
+ enable_thread_safety_force=no
+
+ fi;
+
+ if test $enable_thread_safety = yes -o
+test $enable_thread_safety_force = yes; then
+ enable_thread_safety=yes # for 'force'
+
+ cat confdefs.h \_ACEOF
+ #define ENABLE_THREAD_SAFETY 1
+ _ACEOF
+
+ fi
echo $as_me:$LINENO: result: $enable_thread_safety 5
echo ${ECHO_T}$enable_thread_safety 6
***
*** 17941,17947
# We have to run the thread test near the end so we have all our symbols
# defined. Cross compiling throws a warning.
#
! if test $enable_thread_safety = yes; then
echo $as_me:$LINENO: checking thread safety of required library functions 5
echo $ECHO_N checking thread safety of required library functions... $ECHO_C 6
--- 17972,17991
# We have to run the thread test near the
Re: [HACKERS] thread safety tests
Jan Wieck wrote: On 6/10/2004 2:11 AM, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to be supplied by the connection string in libpq on platforms that want threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)? AFAICS that was not what Jan was suggesting at all. I don't like it either --- changing the user-visible behavior based on whether we think the platform is thread-safe or not is horrid. What I understood Jan to be saying is that we should be willing to build the most thread-safe approximation we can when --enable-thread-safety is requested. Don't bomb out if you don't have getpwuid_r, just give a warning and then use getpwuid. Make it so that --enable-thread-safety bombs out, but make another --enable-thread-safey-anyway work the way Tom descibed it. Done as --enable-thread-safety-force. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] thread safety tests
Bruce Momjian [EMAIL PROTECTED] writes: Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to be supplied by the connection string in libpq on platforms that want threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)? AFAICS that was not what Jan was suggesting at all. I don't like it either --- changing the user-visible behavior based on whether we think the platform is thread-safe or not is horrid. What I understood Jan to be saying is that we should be willing to build the most thread-safe approximation we can when --enable-thread-safety is requested. Don't bomb out if you don't have getpwuid_r, just give a warning and then use getpwuid. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] thread safety tests
On 6/10/2004 2:11 AM, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to be supplied by the connection string in libpq on platforms that want threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)? AFAICS that was not what Jan was suggesting at all. I don't like it either --- changing the user-visible behavior based on whether we think the platform is thread-safe or not is horrid. What I understood Jan to be saying is that we should be willing to build the most thread-safe approximation we can when --enable-thread-safety is requested. Don't bomb out if you don't have getpwuid_r, just give a warning and then use getpwuid. Make it so that --enable-thread-safety bombs out, but make another --enable-thread-safey-anyway work the way Tom descibed it. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] thread safety tests
Jan Wieck wrote: On 6/10/2004 2:11 AM, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to be supplied by the connection string in libpq on platforms that want threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)? AFAICS that was not what Jan was suggesting at all. I don't like it either --- changing the user-visible behavior based on whether we think the platform is thread-safe or not is horrid. What I understood Jan to be saying is that we should be willing to build the most thread-safe approximation we can when --enable-thread-safety is requested. Don't bomb out if you don't have getpwuid_r, just give a warning and then use getpwuid. Make it so that --enable-thread-safety bombs out, but make another --enable-thread-safey-anyway work the way Tom descibed it. Sure, we can do that by just not running the thread_test program. In fact a cross-compile already skips running the test. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] thread safety tests
On 6/10/2004 8:49 AM, Bruce Momjian wrote: Jan Wieck wrote: Make it so that --enable-thread-safety bombs out, but make another --enable-thread-safey-anyway work the way Tom descibed it. Sure, we can do that by just not running the thread_test program. In fact a cross-compile already skips running the test. That sounds good to me. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] thread safety tests
I am wondering why thread_test.c is checking for mktemp()? That function is nowhere used in the libpq. Also, I would suggest that we allow to build the libpq with thread specific compiler options, even if it is not entirely thread safe. It would require that a really multithreaded application has to have mutexes around certain operations, but being entirely unable to configure in a way that adds thread compile options to the CFLAGS makes libpq completely useless for multithreaded programs on some platforms (for example Solaris). Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] thread safety tests
Jan Wieck wrote: I am wondering why thread_test.c is checking for mktemp()? That function is nowhere used in the libpq. Uh, it isn't checking for mktemp, it is using it, and it is using it because someone didn't like hard-coded paths I was using in the past. Is there something wrong with using mktemp? I have heard of no portability problems, except some need six X's, and we updated that. Also, I would suggest that we allow to build the libpq with thread specific compiler options, even if it is not entirely thread safe. It would require that a really multithreaded application has to have mutexes around certain operations, but being entirely unable to configure in a way that adds thread compile options to the CFLAGS makes libpq completely useless for multithreaded programs on some platforms (for example Solaris). I am confused what you are suggesting. Are you saying to use thread flags but not the other things that make is thread-safe? There isn't much else other than the flags actually. Now that more OS's are thread-safe by default, we could consider using threading if it is available by default. We would need some way of reporting that to the user, perhaps via an installed readme file or a pg_config output option. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] thread safety tests
On 6/9/2004 9:36 AM, Bruce Momjian wrote: Also, I would suggest that we allow to build the libpq with thread specific compiler options, even if it is not entirely thread safe. It would require that a really multithreaded application has to have mutexes around certain operations, but being entirely unable to configure in a way that adds thread compile options to the CFLAGS makes libpq completely useless for multithreaded programs on some platforms (for example Solaris). I am confused what you are suggesting. Are you saying to use thread flags but not the other things that make is thread-safe? There isn't much else other than the flags actually. Now that more OS's are thread-safe by default, we could consider using threading if it is available by default. We would need some way of reporting that to the user, perhaps via an installed readme file or a pg_config output option. The problem is that if your thread-safety tests fail, there is no way to build libpq with -pthread and -DREENTRANT or whatever is required on that platform. On Solaris this results in errno being defined as extern int errno; as supposed to #define errno *(errno()) which makes libpq on Solaris completely useless for every program that uses threads for something. There is still value in compiling it with thread support compiler flags, even if it will not result in a thread safe libpq. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] thread safety tests
Jan Wieck wrote:
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the past.
Is there something wrong with using mktemp? I have heard of no
portability problems, except some need six X's, and we updated that.
There seems to be a portability issue here. Stefan Kaltenbrunner
reported a configure failure on sparc64-unknown-openbsd3.5 and the
config.log says:
/tmp//ccx22029.o: In function `main':
/tmp//ccx22029.o(.text+0x8c): warning: mktemp() possibly used unsafely;
consider
using mkstemp()
Yes, I was wondering how mktemp was going to guard against concurrent
access. I have applied the following patch to use mkstemp().
Which is only a warning at this time, it fails later on getpwuid().
Oh, I will need to hear more about that failure.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/tools/thread/thread_test.c
===
RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v
retrieving revision 1.30
diff -c -c -r1.30 thread_test.c
*** src/tools/thread/thread_test.c 28 May 2004 18:37:10 - 1.30
--- src/tools/thread/thread_test.c 9 Jun 2004 15:03:29 -
***
*** 104,110
{
pthread_t thread1,
thread2;
!
if (argc 1)
{
fprintf(stderr, Usage: %s\n, argv[0]);
--- 104,111
{
pthread_t thread1,
thread2;
! int fd;
!
if (argc 1)
{
fprintf(stderr, Usage: %s\n, argv[0]);
***
*** 120,130
/* Make temp filenames, might not have strdup() */
temp_filename_1 = malloc(strlen(TEMP_FILENAME_1) + 1);
strcpy(temp_filename_1, TEMP_FILENAME_1);
! mktemp(temp_filename_1);
temp_filename_2 = malloc(strlen(TEMP_FILENAME_2) + 1);
strcpy(temp_filename_2, TEMP_FILENAME_2);
! mktemp(temp_filename_2);
#if !defined(HAVE_GETADDRINFO) !defined(HAVE_GETHOSTBYNAME_R)
if (gethostname(myhostname, MAXHOSTNAMELEN) != 0)
--- 121,133
/* Make temp filenames, might not have strdup() */
temp_filename_1 = malloc(strlen(TEMP_FILENAME_1) + 1);
strcpy(temp_filename_1, TEMP_FILENAME_1);
! fd = mkstemp(temp_filename_1);
! close(fd);
temp_filename_2 = malloc(strlen(TEMP_FILENAME_2) + 1);
strcpy(temp_filename_2, TEMP_FILENAME_2);
! fd = mkstemp(temp_filename_2);
! close(fd);
#if !defined(HAVE_GETADDRINFO) !defined(HAVE_GETHOSTBYNAME_R)
if (gethostname(myhostname, MAXHOSTNAMELEN) != 0)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] thread safety tests
On 6/9/2004 9:36 AM, Bruce Momjian wrote: Jan Wieck wrote: I am wondering why thread_test.c is checking for mktemp()? That function is nowhere used in the libpq. Uh, it isn't checking for mktemp, it is using it, and it is using it because someone didn't like hard-coded paths I was using in the past. Is there something wrong with using mktemp? I have heard of no portability problems, except some need six X's, and we updated that. There seems to be a portability issue here. Stefan Kaltenbrunner reported a configure failure on sparc64-unknown-openbsd3.5 and the config.log says: /tmp//ccx22029.o: In function `main': /tmp//ccx22029.o(.text+0x8c): warning: mktemp() possibly used unsafely; consider using mkstemp() Which is only a warning at this time, it fails later on getpwuid(). Jan Also, I would suggest that we allow to build the libpq with thread specific compiler options, even if it is not entirely thread safe. It would require that a really multithreaded application has to have mutexes around certain operations, but being entirely unable to configure in a way that adds thread compile options to the CFLAGS makes libpq completely useless for multithreaded programs on some platforms (for example Solaris). I am confused what you are suggesting. Are you saying to use thread flags but not the other things that make is thread-safe? There isn't much else other than the flags actually. Now that more OS's are thread-safe by default, we could consider using threading if it is available by default. We would need some way of reporting that to the user, perhaps via an installed readme file or a pg_config output option. -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] thread safety tests
On 6/9/2004 11:45 AM, Bruce Momjian wrote: Jan Wieck wrote: The problem is that if your thread-safety tests fail, there is no way to build libpq with -pthread and -DREENTRANT or whatever is required on that platform. On Solaris this results in errno being defined as extern int errno; as supposed to #define errno *(errno()) which makes libpq on Solaris completely useless for every program that uses threads for something. There is still value in compiling it with thread support compiler flags, even if it will not result in a thread safe libpq. Well, first we should find out how to get the thread test to pass for that patform, but for cases where we can't (FreeBSD doesn't have getpwuid_r(), we are stuck. (That might be your Solaris problem as well.) There is no problem with thread safety on Solaris. The configure script for 7.4.2 is broken for it, leading to a broken libpq when using --enable-thread-safey. I looked over the code and the only place getpwuid_r (through pqGetpwuid) is used is in libpq to look up the default username based on the euid for the connection to the backend. Unfortunately, I can't find any other way to do such a lookup in a thread-safe manner unless we do a system() or lock/read /etc/passwd ourselves, both of which are ugly. I can't imagine how some OS's cannot give us a thread-safe way to do this. When FreeBSD can't enable threads in 7.5, folks are going to be upset. In 7.4 we allowed it by having our own C code lock/copy the passwd structure, but someone pointed out that calls to getpwuid() in other places in the client code don't have such locking, so it would not work, so it was removed for 7.5. I disagree that all or nothing is a good strategy. What you have changed this to is to deny using PostgreSQL from multithreaded applications on platforms that have no getpwuid_r() altogether, if their platform happens to require any thread special compiler options for libpq to work in general. Take Slony as an example. It is multithreaded, and we aren't happy that we have to guard the pg_connect() call with a mutex against multiple concurrent calls. But since our connections are of long living nature this is no problem. And nowhere else in the entire code is any call to getpwuid() or anything else. So we have the situation under control. But I really don't want to tell people in the build instructions that they have to edit libpq's Makefile because PostgreSQL's ./configure script is too restrictive. And just to make your day, your tests for thread safety are incomplete. The reason why we use a mutex now on all platforms, thread safe or not, is because in the event you have a kerberos lib available (which is not thread safe), pg_connect() can crash wether you use kerberos or not. So I think when compiling for --enable-thread-safe we should disable kerberos in libpq, right? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] thread safety tests
On 6/9/2004 11:16 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the past.
Is there something wrong with using mktemp? I have heard of no
portability problems, except some need six X's, and we updated that.
There seems to be a portability issue here. Stefan Kaltenbrunner
reported a configure failure on sparc64-unknown-openbsd3.5 and the
config.log says:
/tmp//ccx22029.o: In function `main':
/tmp//ccx22029.o(.text+0x8c): warning: mktemp() possibly used unsafely;
consider
using mkstemp()
Yes, I was wondering how mktemp was going to guard against concurrent
access. I have applied the following patch to use mkstemp().
Which is only a warning at this time, it fails later on getpwuid().
Oh, I will need to hear more about that failure.
The relevant part of the config.log is:
configure:17942: checking thread safety of required library functions
configure:17967: gcc -o conftest -O2 -fno-strict-aliasing -pthread
-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -DIN_CONFIGURE
conftest.c -lz -lreadline -lcurses -lresolv -lcompat -lm
-lutil 5
/tmp//ccx22029.o: In function `main':
/tmp//ccx22029.o(.text+0x8c): warning: mktemp() possibly used unsafely;
consider using mkstemp()
configure:17970: $? = 0
configure:17972: ./conftest
Your errno is thread-safe.
Your system has sterror_r(); it does not need strerror().
Your system uses getpwuid() which is not thread-safe. **
Your system has getaddrinfo(); it does not need gethostbyname()
or gethostbyname_r().
** YOUR PLATFORM IS NOT THREAD-SAFE. **
configure:17975: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 17961 configure
#include confdefs.h
#include ./src/tools/thread/thread_test.c
configure:17984: result: no
configure:17986: error:
*** Thread test program failed. Your platform is not thread-safe.
*** Check the file 'config.log'for the exact reason.
Index: src/tools/thread/thread_test.c
===
RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v
retrieving revision 1.30
diff -c -c -r1.30 thread_test.c
*** src/tools/thread/thread_test.c 28 May 2004 18:37:10 - 1.30
--- src/tools/thread/thread_test.c 9 Jun 2004 15:03:29 -
***
*** 104,110
{
pthread_t thread1,
thread2;
!
if (argc 1)
{
fprintf(stderr, Usage: %s\n, argv[0]);
--- 104,111
{
pthread_t thread1,
thread2;
! int fd;
!
if (argc 1)
{
fprintf(stderr, Usage: %s\n, argv[0]);
***
*** 120,130
/* Make temp filenames, might not have strdup() */
temp_filename_1 = malloc(strlen(TEMP_FILENAME_1) + 1);
strcpy(temp_filename_1, TEMP_FILENAME_1);
! mktemp(temp_filename_1);
temp_filename_2 = malloc(strlen(TEMP_FILENAME_2) + 1);
strcpy(temp_filename_2, TEMP_FILENAME_2);
! mktemp(temp_filename_2);
#if !defined(HAVE_GETADDRINFO) !defined(HAVE_GETHOSTBYNAME_R)
if (gethostname(myhostname, MAXHOSTNAMELEN) != 0)
--- 121,133
/* Make temp filenames, might not have strdup() */
temp_filename_1 = malloc(strlen(TEMP_FILENAME_1) + 1);
strcpy(temp_filename_1, TEMP_FILENAME_1);
! fd = mkstemp(temp_filename_1);
! close(fd);
temp_filename_2 = malloc(strlen(TEMP_FILENAME_2) + 1);
strcpy(temp_filename_2, TEMP_FILENAME_2);
! fd = mkstemp(temp_filename_2);
! close(fd);
#if !defined(HAVE_GETADDRINFO) !defined(HAVE_GETHOSTBYNAME_R)
if (gethostname(myhostname, MAXHOSTNAMELEN) != 0)
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] thread safety tests
Jan Wieck wrote: On 6/9/2004 11:45 AM, Bruce Momjian wrote: Jan Wieck wrote: The problem is that if your thread-safety tests fail, there is no way to build libpq with -pthread and -DREENTRANT or whatever is required on that platform. On Solaris this results in errno being defined as extern int errno; as supposed to #define errno *(errno()) which makes libpq on Solaris completely useless for every program that uses threads for something. There is still value in compiling it with thread support compiler flags, even if it will not result in a thread safe libpq. Well, first we should find out how to get the thread test to pass for that patform, but for cases where we can't (FreeBSD doesn't have getpwuid_r(), we are stuck. (That might be your Solaris problem as well.) There is no problem with thread safety on Solaris. The configure script for 7.4.2 is broken for it, leading to a broken libpq when using --enable-thread-safey. Oh, yes, to be fixed in 7.4.3. I looked over the code and the only place getpwuid_r (through pqGetpwuid) is used is in libpq to look up the default username based on the euid for the connection to the backend. Unfortunately, I can't find any other way to do such a lookup in a thread-safe manner unless we do a system() or lock/read /etc/passwd ourselves, both of which are ugly. I can't imagine how some OS's cannot give us a thread-safe way to do this. When FreeBSD can't enable threads in 7.5, folks are going to be upset. In 7.4 we allowed it by having our own C code lock/copy the passwd structure, but someone pointed out that calls to getpwuid() in other places in the client code don't have such locking, so it would not work, so it was removed for 7.5. I disagree that all or nothing is a good strategy. What you have changed this to is to deny using PostgreSQL from multithreaded applications on platforms that have no getpwuid_r() altogether, if their platform happens to require any thread special compiler options for libpq to work in general. Yes, this was the agreed approach. It wasn't all my idea. Take Slony as an example. It is multithreaded, and we aren't happy that we have to guard the pg_connect() call with a mutex against multiple concurrent calls. But since our connections are of long living nature this is no problem. And nowhere else in the entire code is any call to getpwuid() or anything else. So we have the situation under control. But I really don't want to tell people in the build instructions that they have to edit libpq's Makefile because PostgreSQL's ./configure script is too restrictive. Yep, a problem. However, when we create libpq we can't know that your app isn't going to call getpwuid itself, can we; and even if we did, we couldn't know if other libraries you are calling are using it. I bet you don't even know that. And just to make your day, your tests for thread safety are incomplete. Why incomplete? Because it doesn't handle kerberos? See below. The reason why we use a mutex now on all platforms, thread safe or not, is because in the event you have a kerberos lib available (which is not thread safe), pg_connect() can crash wether you use kerberos or not. So I think when compiling for --enable-thread-safe we should disable kerberos in libpq, right? I thought we added kerberos locking to our current CVS. As for your general issue, I don't think we want to head down the road of having a libpq that is safe only if certain qualifications are made of clients calling it. If folks know enough to deal with those qualifications, they can use CFLAGS to pass compiler flags to their libpq build or hack up the code to bypass the thread checks. What we really need is a way to do the uid-username mapping in a thread-safe way. Could we check the environment for $USER or $LOGNAME? Could we require them to be set for thread builds on OS's without getpwuid_r and in cases where the username is not specified in the connection string? If FreeBSD and Solaris both have this issue, it is important for us to solve it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] thread safety tests
Well, looks like you are missing getpwuid_r():
Your system uses getpwuid() which is not thread-safe. **
and we don't have any workaround for this.
---
Jan Wieck wrote:
On 6/9/2004 11:16 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the past.
Is there something wrong with using mktemp? I have heard of no
portability problems, except some need six X's, and we updated that.
There seems to be a portability issue here. Stefan Kaltenbrunner
reported a configure failure on sparc64-unknown-openbsd3.5 and the
config.log says:
/tmp//ccx22029.o: In function `main':
/tmp//ccx22029.o(.text+0x8c): warning: mktemp() possibly used unsafely;
consider
using mkstemp()
Yes, I was wondering how mktemp was going to guard against concurrent
access. I have applied the following patch to use mkstemp().
Which is only a warning at this time, it fails later on getpwuid().
Oh, I will need to hear more about that failure.
The relevant part of the config.log is:
configure:17942: checking thread safety of required library functions
configure:17967: gcc -o conftest -O2 -fno-strict-aliasing -pthread
-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -DIN_CONFIGURE
conftest.c -lz -lreadline -lcurses -lresolv -lcompat -lm
-lutil 5
/tmp//ccx22029.o: In function `main':
/tmp//ccx22029.o(.text+0x8c): warning: mktemp() possibly used unsafely;
consider using mkstemp()
configure:17970: $? = 0
configure:17972: ./conftest
Your errno is thread-safe.
Your system has sterror_r(); it does not need strerror().
Your system uses getpwuid() which is not thread-safe. **
Your system has getaddrinfo(); it does not need gethostbyname()
or gethostbyname_r().
** YOUR PLATFORM IS NOT THREAD-SAFE. **
configure:17975: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 17961 configure
#include confdefs.h
#include ./src/tools/thread/thread_test.c
configure:17984: result: no
configure:17986: error:
*** Thread test program failed. Your platform is not thread-safe.
*** Check the file 'config.log'for the exact reason.
Index: src/tools/thread/thread_test.c
===
RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v
retrieving revision 1.30
diff -c -c -r1.30 thread_test.c
*** src/tools/thread/thread_test.c 28 May 2004 18:37:10 - 1.30
--- src/tools/thread/thread_test.c 9 Jun 2004 15:03:29 -
***
*** 104,110
{
pthread_t thread1,
thread2;
!
if (argc 1)
{
fprintf(stderr, Usage: %s\n, argv[0]);
--- 104,111
{
pthread_t thread1,
thread2;
! int fd;
!
if (argc 1)
{
fprintf(stderr, Usage: %s\n, argv[0]);
***
*** 120,130
/* Make temp filenames, might not have strdup() */
temp_filename_1 = malloc(strlen(TEMP_FILENAME_1) + 1);
strcpy(temp_filename_1, TEMP_FILENAME_1);
! mktemp(temp_filename_1);
temp_filename_2 = malloc(strlen(TEMP_FILENAME_2) + 1);
strcpy(temp_filename_2, TEMP_FILENAME_2);
! mktemp(temp_filename_2);
#if !defined(HAVE_GETADDRINFO) !defined(HAVE_GETHOSTBYNAME_R)
if (gethostname(myhostname, MAXHOSTNAMELEN) != 0)
--- 121,133
/* Make temp filenames, might not have strdup() */
temp_filename_1 = malloc(strlen(TEMP_FILENAME_1) + 1);
strcpy(temp_filename_1, TEMP_FILENAME_1);
! fd = mkstemp(temp_filename_1);
! close(fd);
temp_filename_2 = malloc(strlen(TEMP_FILENAME_2) + 1);
strcpy(temp_filename_2, TEMP_FILENAME_2);
! fd = mkstemp(temp_filename_2);
! close(fd);
#if !defined(HAVE_GETADDRINFO) !defined(HAVE_GETHOSTBYNAME_R)
if (gethostname(myhostname, MAXHOSTNAMELEN) != 0)
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#== [EMAIL PROTECTED] #
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square,
Re: [HACKERS] thread safety tests
On 6/9/2004 1:04 PM, Bruce Momjian wrote: What we really need is a way to do the uid-username mapping in a thread-safe way. Could we check the environment for $USER or $LOGNAME? Could we require them to be set for thread builds on OS's without getpwuid_r and in cases where the username is not specified in the connection string? Maybe not as popular, but what about breaking backward compatibility and require the DB name to be specified, no username fallback? How many applications really rely on that feature? And people who are used to it from the commandline can set PGDATABASE in their .profile to get it back. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] thread safety tests
Jan Wieck wrote: On 6/9/2004 1:04 PM, Bruce Momjian wrote: What we really need is a way to do the uid-username mapping in a thread-safe way. Could we check the environment for $USER or $LOGNAME? Could we require them to be set for thread builds on OS's without getpwuid_r and in cases where the username is not specified in the connection string? Maybe not as popular, but what about breaking backward compatibility and require the DB name to be specified, no username fallback? How many applications really rely on that feature? And people who are used to it from the commandline can set PGDATABASE in their .profile to get it back. That is only part of where the username is used. I assume it is also used for connections when the username isn't supplied, not just as the default for the database name. Basically on those platforms, either the username would have to be in the environment, or supplied as part of the connection string. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] thread safety tests
On 6/9/2004 1:44 PM, Bruce Momjian wrote: Jan Wieck wrote: On 6/9/2004 1:04 PM, Bruce Momjian wrote: What we really need is a way to do the uid-username mapping in a thread-safe way. Could we check the environment for $USER or $LOGNAME? Could we require them to be set for thread builds on OS's without getpwuid_r and in cases where the username is not specified in the connection string? Maybe not as popular, but what about breaking backward compatibility and require the DB name to be specified, no username fallback? How many applications really rely on that feature? And people who are used to it from the commandline can set PGDATABASE in their .profile to get it back. That is only part of where the username is used. I assume it is also used for connections when the username isn't supplied, not just as the default for the database name. Basically on those platforms, either the username would have to be in the environment, or supplied as part of the connection string. We have PGUSER, PGHOST, PGPORT, PGDATABASE, all of them you can set in your .profile, why do we need to lookup the uid at all? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] thread safety tests
Jan Wieck wrote: On 6/9/2004 1:44 PM, Bruce Momjian wrote: Jan Wieck wrote: On 6/9/2004 1:04 PM, Bruce Momjian wrote: What we really need is a way to do the uid-username mapping in a thread-safe way. Could we check the environment for $USER or $LOGNAME? Could we require them to be set for thread builds on OS's without getpwuid_r and in cases where the username is not specified in the connection string? Maybe not as popular, but what about breaking backward compatibility and require the DB name to be specified, no username fallback? How many applications really rely on that feature? And people who are used to it from the commandline can set PGDATABASE in their .profile to get it back. That is only part of where the username is used. I assume it is also used for connections when the username isn't supplied, not just as the default for the database name. Basically on those platforms, either the username would have to be in the environment, or supplied as part of the connection string. We have PGUSER, PGHOST, PGPORT, PGDATABASE, all of them you can set in your .profile, why do we need to lookup the uid at all? In case they don't set it, which is very common, I am sure. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] thread safety tests
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to be supplied by the connection string in libpq on platforms that want threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)? If so, I can easily create a patch and apply it. --- Jan Wieck wrote: On 6/9/2004 1:44 PM, Bruce Momjian wrote: Jan Wieck wrote: On 6/9/2004 1:04 PM, Bruce Momjian wrote: What we really need is a way to do the uid-username mapping in a thread-safe way. Could we check the environment for $USER or $LOGNAME? Could we require them to be set for thread builds on OS's without getpwuid_r and in cases where the username is not specified in the connection string? Maybe not as popular, but what about breaking backward compatibility and require the DB name to be specified, no username fallback? How many applications really rely on that feature? And people who are used to it from the commandline can set PGDATABASE in their .profile to get it back. That is only part of where the username is used. I assume it is also used for connections when the username isn't supplied, not just as the default for the database name. Basically on those platforms, either the username would have to be in the environment, or supplied as part of the connection string. We have PGUSER, PGHOST, PGPORT, PGDATABASE, all of them you can set in your .profile, why do we need to lookup the uid at all? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] thread safety
Bruce Momjian [EMAIL PROTECTED] wrote: The thing that slows me down the most --- trips like FOSDEM. I am doing one every month or every other month. That takes 1/4 of each month. The threading discussion took 1/1000 of a month, but I do several hundred of those, so it fills up a month quickly. I understand you, I seen you there just two day and seem that you are someone that is not able to say: NO. I remember that in Bruxelles Peter Eisentraut was there too, why not found some one that replace you? Some time at least :-) Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] thread safety
[ CC to advocacy.] Mendola Gaetano wrote: Bruce Momjian [EMAIL PROTECTED] wrote: The thing that slows me down the most --- trips like FOSDEM. I am doing one every month or every other month. That takes 1/4 of each month. The threading discussion took 1/1000 of a month, but I do several hundred of those, so it fills up a month quickly. I understand you, I seen you there just two day and seem that you are someone that is not able to say: NO. I can say no if this group tells me it is more important that I focus on PostgreSQL development and not on the speeches. The question is what is going to advance PostgreSQL faster. I remember that in Bruxelles Peter Eisentraut was there too, why not found some one that replace you? Some time at least :-) We do have other people doing events all the time. Comdex will be attended by a lot of our folks. We also have folks attending local user group meetings and making speeches. However, many presentations have special requirements: o full-time employed in PostgreSQL, or willing to take vacation time to make those speeches o ability to speak in front of a large groups and communicate well o ability to create long presentations o someone visible in PostgreSQL who can act as a representative No, not all events require all those items, but many do, and that's why I end up doing them. I don't mind it (it is quite interesting) but it does take me away from managing PostgreSQL. (I have also started taking my 10-year-old son with me, and that is fun.) I almost always offer to give them a local person who can make a presentation in their native language. Sometimes they accept that, but mostly they don't. :-) FYI, I am often able to merge two events into one trip. For the FOSDEM talk, I came from a talk in Japan, and after the Denmark talk in January, I will travel to Paris for a talk on February 3-5. (I will post that event to the PostgreSQL news page now.) Also, consider that I work at home, so I am home 100% of the time when I am not traveling, so the trips aren't as difficult as they would be for someone who is at work for 12 hours every weekday. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] thread safety
Mendola Gaetano wrote: I seen on this list a lot of energy ( also little flames involving SCO Co. ) spent on thread safety; was really necessary spent so much energy in this direction? I was at Fosdem in Bruxelles ( I spoke there about the use of postgres in my project ) and I seen al people there was really exicited about the anticipation of Bruce Momjian about the PITR in 7.4 but how we know there was no time for it May be I'm wrong but I'd like know why thread safety was so necessary. The thing that slows me down the most --- trips like FOSDEM. I am doing one every month or every other month. That takes 1/4 of each month. The threading discussion took 1/1000 of a month, but I do several hundred of those, so it fills up a month quickly. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] thread safety
On Tue, 2 Sep 2003 03:06 am, Mendola Gaetano wrote: May be I'm wrong but I'd like know why thread safety was so necessary. It bugged Lee enough that he went and wrote a patch for it. It bugged me enough that I couldn't use it on our choice of platform (older Linux) that I did some little fixes for that. I worked on what I needed. If you need a justification for ECPG threading support: people porting from Sybase/Informix/Oracle would probably expect ECPG to support threads, and will get a nasty surprise when their ported application abruptly dies. I expected it to just work and was unpleasantly surprised when it didn't. Best Regards, Philip Yarra. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] thread safety
I seen on this list a lot of energy ( also little flames involving SCO Co. ) spent on thread safety; was really necessary spent so much energy in this direction? I was at Fosdem in Bruxelles ( I spoke there about the use of postgres in my project ) and I seen al people there was really exicited about the anticipation of Bruce Momjian about the PITR in 7.4 but how we know there was no time for it May be I'm wrong but I'd like know why thread safety was so necessary. Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] thread safety
Probably because I worked on thread safety and produced a patch. If someone done the same for PITR and produced a patch i'm sure it would have generated much more interest. I couldn't have done PITR, so no loss of resource there. Was Bruce planning to do the PITR work? If so I guess a lot of his time's been spent on integrating patches and the like - leaving less time for other developments. L. Mendola Gaetano writes: I seen on this list a lot of energy ( also little flames involving SCO Co. ) spent on thread safety; was really necessary spent so much energy in this direction? I was at Fosdem in Bruxelles ( I spoke there about the use of postgres in my project ) and I seen al people there was really exicited about the anticipation of Bruce Momjian about the PITR in 7.4 but how we know there was no time for it May be I'm wrong but I'd like know why thread safety was so necessary. Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] thread safety
On Mon, Sep 01, 2003 at 18:16:25 +0100, Lee Kindness [EMAIL PROTECTED] wrote: Was Bruce planning to do the PITR work? If so I guess a lot of his time's been spent on integrating patches and the like - leaving less time for other developments. Bruce was working on the WIN32 port. That will also not make it into 7.4 as a working port. Someone else was working on PITR. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
