Bruce Momjian wrote:
I think we ought to detect the console type automatically anyway.
Certainly we don't want people to have to set this variables all the time.
Agreed. Automatic is ideal. Any ideas out there?
Does input from the console work correctly right now?
What about setting th
Christoph Dalitz wrote:
On Thu, 11 Sep 2003 20:51:24 +0200
Manfred Spraul <[EMAIL PROTECTED]> wrote:
- OemToChar() and CharToOem() convert all console input/output. In the
long run this might be the better solution, if it works entirely without
user intervention. I'm not s
Peter Eisentraut wrote:
If you can detect that they are different, why can't you adjust the code
page in that case only?
What should we do if we detect that they differ:
- set the console code page to the ansi code page. This has two
drawbacks: It doesn't work with Indic, because Indic doesn't
Attached is a patch that aligns large shared memory allocations beyond
MAXIMUM_ALIGNOF. The reason for this is that Intel's cpus have a fast
path for bulk memory copies that only works with aligned addresses. It's
possible that other cpus have similar restrictions.
With 7.3.4, it achives a 5% pe
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
Attached is a patch that aligns large shared memory allocations beyond
MAXIMUM_ALIGNOF. The reason for this is that Intel's cpus have a fast
path for bulk memory copies that only works with aligned addresses.
Th
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Of course, the linux kernel is aimed at a limited set of compilers - as I
understand it basically gcc although it has been made to build with Intel
compilers
icc once compiled the kernel. But they had to teach it quite a lots of
gcci
I've asked the question on the gcc devel list. The first reply was that
MemSet violates strict aliasing rules:
http://gcc.gnu.org/ml/gcc/2003-10/msg00524.html
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
--
Manfred
--
Tom Lane wrote:
Given that gcc is smart enough not to move any code across the memset()
call, I doubt that it would be moving anything across the whole if()
construct. Now if the if-condition were such that the memset code path
could be optimized away, then we'd have a problem, but in practice I
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
After some massaging, I've succeeded in generating bad code using a
slightly modified MemSetAligned macro (parameters -O2
-fstrict-aliasing): gcc pipelined the x*x around the memset.
As I already explained, we do not
pqsecure_write tries to catch SIGPIPE signals generated by network
disconnects by setting the signal handler to SIG_IGN. The current
approach causes several problems:
- it always sets SA_RESTART when it restores the old handler.
- it's not reliable for multi threaded apps, because another thread
Attatched is the latest version of my patch that makes the
signal(SIG_PIPE, SIG_IGN) calls around the send() syscall conditional:
they are not sufficient to ensure that multithreaded libpq users are not
killed by SIGPIPE signals, and they cause a noticable slowdown.
I've switched to a global fla
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I think this is the patch I like.
The #if coding is messy and unnecessary. You could do the test as per
the non-POSIX variant using two calls of pqsignal(), and not have any
system dependence here, nor a need for .
What about mu
Tom Lane wrote:
I don't think we need to complicate pqsignal's API for this. Instead
we'd better document that SIGPIPE handling has to be set up and kept
stable before doing any libpq operations in a multithread app.
Not reliable.
An app could install it's own signal handler and block SIGPIPE
Hi,
attached is an update of my automatic sigaction patch: I've moved the
actual sigaction calls into pqsignal.c and added a helper function
(pgsignalinquire(signo)). I couldn't remove the include from
fe-connect.c: it's required for the SIGPIPE definition.
Additionally I've added a -a flag fo
Bruce Momjian wrote:
Better. However, I am confused over when we do sigaction. I thought we
were going to do it only if they had a signal handler defined, meaning
if (pipehandler != SIG_DFL &&
pipehandler != SIG_IGN &&
pipehandler != SIG_ERR)
conn-
Tom Lane wrote:
Seriously though, if we can move the bulk of the writing work into
background processes then I don't believe that there will be any
significant penalty for regular backends. And I believe that it would
be a huge advantage from a correctness point of view if we could stop
depending
Bruce Momjian wrote:
I thought it should be global too, basically testing on the first
connection request.
What if two PQconnect calls happen at the same time?
I would really prefer the manual approach with a new PQsetsighandler
function - the autodetection is fragile, it's trivial to find a spec
Bruce Momjian wrote:
Here is my logic --- 99% of apps don't install a SIGPIPE signal handler,
and 90% will not add a SIGPIPE/SIG_IGN call to their applications. I
guess I am looking for something that would allow the performance
benefit of not doing a pgsignal() call around very send() for the
ma
Bruce Momjian wrote:
OK, I know you had a flag for pgbench, and that doesn't use threads.
What speedup do you see there?
Tiny. I added the flag to check that my implementation works, not as a
benchmark tool.
I would not expect a library to require me to do something in my code to
be thread-s
Neil Conway wrote:
A quick grep of the source tree indicates that the following files
claim to be covered by the 4 clause BSD license:
$ grep -rlI 'This product includes software developed' *
contrib/mysql/my2pg.pl
contrib/pgcrypto/README.pgcrypto
contrib/pgcrypto/blf.c
You must be careful wit
Shridhar Daithankar wrote:
Does 30% difference above count as significant?
No. It's Linux, we can look at the sources: there is no per-fd cache,
the page cache is global. Thus fsync() syncs the whole cache to disk.
A problem could only occur if the file cache is not global - perhaps a
per-nod
Hi,
Intel recommends to add a special pause instruction into spinlock busy
loops. It's necessary for hyperthreading - without it, the cpu can't
figure out that a logical thread does no useful work and incorrectly
awards lots of execution resources to that thread. Additionally, it's
supposed to
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
Intel recommends to add a special pause instruction into spinlock busy
loops. It's necessary for hyperthreading - without it, the cpu can't
figure out that a logical thread does no useful work and incorrectly
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Don't you have to put it in a specific place in the loop to make that
work? If not, why not?
Rep;nop is just a short delay - that's all.
That view seems to me to be directly cont
Tom Lane wrote:
Anyway, I've committed your patch with some changes.
Thanks.
BTW, I noticed a lot of concern in the Intel app notes about reserving
64 or even 128 bytes for each spinlock to avoid cache line conflicts.
That seems excessive to me (we use a lot of spinlocks for buffers), but
perh
Tom Lane wrote:
Is there an easy way find out which LWLock is contended?
Not from oprofile output, as far as I can think. I've suspected for
some time that the BufMgrLock is a major bottleneck, but have no proof.
Mark ran a DBT-2 testrun with the attached statistics patch applied: It
col
Bruce Momjian wrote:
+ /*
+* We could lose a signal during this test.
+* In a multi-threaded application, this might
+* be a problem. Do any non-threaded platforms
Threaded or non-threaded?
+* lack sigaction()?
+*/
Additionally, the p
Bruce Momjian wrote:
I could not get this patch to compile. I am getting a failure because
BSD/OS doesn't have pthread_rwlock_wrlock(). I am concerned other
platforms might not have it either.
I feared that. I'll switch to pthread_mutex_lock()+_unlock().
pthread_rwlock_wrlock()+_unlock was fa
ll return 0 on success and -1 on failure, which will
be interpreted just the other way round in initialize_SSL.
Patch appended.
Hmm, that looks backwards to me too, but this would seem to imply that
Manfred Spraul failed to test his last patch at all. Manfred, care to
explain why we shouldn&#
Bruce Momjian wrote:
- patch for thread_test.c needed posted some hours ago.
Applied.
The current CVS tree work again, Andreas' patch fixed the configure failure.
Additionally Andreas' libpq patch fixes ssl. I've tested the locking,
too: ssl calls pq_lockingcallback.
I've tested it by add
Andreas Pflug wrote:
I don't really think so. That mutex_initialized is a globally static
variable, not a thread local one. Thread interruption between testing
mutex_initialized and setting it is very unlikely and still wouldn't
do much harm if it actually does happen.
Very unlikely is not a go
Andreas Pflug wrote:
Bruce Momjian wrote:
Agreed. My pthread book says pthread_mutex_init() should be called only
once, and we have to guarantee that. If the Windows implentation allows
it to be called multiple times, just create a function to be called only
by Win32 that does that and leave the
Hi,
win32 doesn't support a static initializer for mutexes, thus the first
user must initialize the lock. The problem are concurrent "first" users
- the pthread_mutex_t initialization must be synchronized.
The current implementation is broken, the attached patches fixes that:
mutex_initlock is a
Hi,
The win32 port doesn't have a native user space spinlock implementation
yet. Attached is an untested patch - could someone test it? I don't have
Visual C++.
--
Manfred
Index: src/include/storage/s_lock.h
===
RCS file: /projec
Bruce Momjian wrote:
Because we don't support non-gcc Win32 builds of the backend, adding
this patch doesn't make sense. If we ever start to support non-gcc
Win32 backends we can add this.
Ok. I wasn't aware that the backend is gcc-only.
But what about my libpq patch? Races in the library start
35 matches
Mail list logo
