On 2/28/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
There's a signficant difference between not calling flush 'anytime soon'
and lazy writes, however :)
No - not really.
If this was a flag to apr_sdbm_open, or was modified to interact with
the existing locking logic, I'd have much more
On Wed, Feb 28, 2007 at 01:12:05AM -0800, Justin Erenkrantz wrote:
On 2/28/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
If this was a flag to apr_sdbm_open, or was modified to interact with
the existing locking logic, I'd have much more faith that this is
a reasonable approach.
The
On 2/28/07, Joe Orton [EMAIL PROTECTED] wrote:
The caller could already pass in APR_BUFFERED in the mode parameter to
apr_sdbm_open(), AFAICS.
Well, that doesn't help apr_dbm_* - which doesn't permit such flags to
be passed. I only realized after I committed that we even had a
bypass
On Wed, Feb 28, 2007 at 08:29:10AM -0800, Justin Erenkrantz wrote:
The performance implications of not doing buffered reads just *kills*
our server - so we need to do something and adding buffering lessens
the load quite dramatically. In our situation, we couldn't care less
about modifying
On 2/28/07, Joe Orton [EMAIL PROTECTED] wrote:
No, that sounds fine, or just moving your change up inside the !(flags
APR_WRITE) condition so that all apr_sdbm_* users benefit equally.
Latter done in r512842. Thanks. -- justin
On 2/28/07, André Malo [EMAIL PROTECTED] wrote:
I do assume, that should be |=, shouldn't it? ;-)
Ergh. Yah. Stupid CP from the sharelock and I didn't pay attention
to the fact that it was negated.
Doh. Fixed in r512867. -- justin
Joe Orton wrote:
On Wed, Feb 28, 2007 at 08:29:10AM -0800, Justin Erenkrantz wrote:
The performance implications of not doing buffered reads just *kills*
our server - so we need to do something and adding buffering lessens
the load quite dramatically. In our situation, we couldn't care
On 28/02/2007, at 15:31, Justin Erenkrantz wrote:
On 2/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Wed Feb 28 10:05:37 2007
New Revision: 512882
URL: http://svn.apache.org/viewvc?view=revrev=512882
Log:
Fix apr_file_writev when buffering is enabled by forcing a
On 2/28/07, Davi Arnaut [EMAIL PROTECTED] wrote:
apr_file_flush does that.
Ugh, we're not doing an fsync()? We should be if the user calls
flush. -- justin
On 2/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Wed Feb 28 10:05:37 2007
New Revision: 512882
URL: http://svn.apache.org/viewvc?view=revrev=512882
Log:
Fix apr_file_writev when buffering is enabled by forcing a flush, rather than
writing underneath the write
Joe Orton wrote:
On Wed, Feb 28, 2007 at 08:29:10AM -0800, Justin Erenkrantz wrote:
The performance implications of not doing buffered reads just *kills*
our server - so we need to do something and adding buffering lessens
the load quite dramatically. In our situation, we couldn't care less
Another alternative, we can either write lock the file by all readers,
or perhaps easier but probably more cpu intensive, lstat to pick up the
modification stamp?
I'm still apprehensive about the assumptions here, if our buffering was
block oriented this wouldn't be an issue, but the SDBM is
Joe Orton wrote:
On Wed, Feb 28, 2007 at 01:12:05AM -0800, Justin Erenkrantz wrote:
On 2/28/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
If this was a flag to apr_sdbm_open, or was modified to interact with
the existing locking logic, I'd have much more faith that this is
a reasonable
On 2/28/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Sounds great. Let's move this hack to apr_dbm_open's delegate for
apr_sdbm_open, and simply ensure apr_sdbm_open honors the APR_BUFFERED
flag.
If this is moved to apr_dbm_, and this flag true for any SDBM that isn't
APR_SHARELOCK'ed,
Sorry if this is feeling like fetch me a rock, I was offering suggestions.
-1 to the code committed this week if there is no APR_NOTBUFFERED flag
to apr_sdbm_open(), period.
So, how to infer APR_BUFFERED? Since apr_dbm_open doesn't pass APR_SHARELOCK
it can safely pass APR_BUFFERED from its
This patch looks right, +1 The last comment vetoed the code in trunk,
not your patch below, and explained my rational.
Sorry for confusion, and thanks!
Bill
Justin Erenkrantz wrote:
On 2/28/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Sounds great. Let's move this hack to
On Wed, 2007-02-28 at 22:16 -0500, Tom Donovan wrote:
re: could you also address the M4 stuff in your patch?
Done. This patch removes the no-longer-needed reference to
APU_DSO_BUILD from dbd.m4.
Thanks! I will wait for Joe's feedback, since he was the one that
created the original
On Wed, 2007-02-28 at 22:16 -0500, Tom Donovan wrote:
This worked for me on both Windows and Linux.
One question here - what does the output of ldd .libs/libaprutil-1.so
look like on the Linux box?
--
Bojan
In this test, pgsql was the static driver, mysql was dynamic.
libaprutil-1.so looks like this:
# ldd libaprutil-1.so
linux-gate.so.1 = (0xe000)
libpq.so.4 = /usr/lib/libpq.so.4 (0xb7f65000)
libexpat.so.0 = /opt/test264/lib/libexpat.so.0 (0xb7f49000)
At first I was concerned that there was no PostgreSQL lib shown for
libaprutil-1,
but looking at the build - it apparently links with the static PostgreSQL
library: libpq.a.
Aha! That explains it. The pq (PQ) instead of pg (PG) seems odd, but it's
in pgsql/lib.
-tom-
Bojan Smojver wrote:
On Thu, 2007-03-01 at 00:03 -0500, Tom Donovan wrote:
At first I was concerned that there was no PostgreSQL lib shown for
libaprutil-1,
but looking at the build - it apparently links with the static PostgreSQL
library: libpq.a.
Aha! That explains it. The pq (PQ) instead of pg (PG)
21 matches
Mail list logo
