apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: [PATCH]: improved error reporting for apr_dbd_mysql.c - correct version
Date Mon, 22 May 2006 05:47:27 GMT
Quoting Alex Dubov <oakad@yahoo.com>:

> What the oracle does if BEFORE UPDATE trigger prevents
> updating of matched rows? I believe that matched rows
> will only differ from "updated" ones in the presence
> of suitable trigger.

No idea. I just tried a simple update with identical data. I reported  
that the row changed.

>> MAX_FIELD_SIZE_24MB
> I just thought that no such trickery is needed with
> linux. Linux (and curiously WinCE, but not Win32) use
> speculative allocation, so one can actually malloc 2GB
> of space without much problems and with only 1 page of
> wasted RAM (given a 64b addresses or proper kernel).
> Of course, this is not so portable behaviour.

Yeah, I noticed that on FC5 there are no complaints about large  
allocations (i.e. my 700MB box happily allocated multiple 4 GB chunks  
- OUCH!). I'd much rather see this kind of thing explicitly enabled  
for security reasons. Maybe MAX_FIELD_SIZE_UNLIMITED?

> And for
> some reason (I just noticed it), apr_palloc is
> synonymous to apr_pcalloc and does memset on allocated
> region - this is very bad in light of the above. Given
> this, can we have a apr_xxalloc function that does not
> touches allocated block? This will make a great
> improvement in physical memory usage (at least on
> linux).

I'll leave this one to folks that understand portablility of memory  
allocation a bit better than myself.

-- 
Bojan

Mime
View raw message