Quoting Alex Dubov <[EMAIL PROTECTED]>:
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
