[syslog-ng] merging stuff from merge-queue/3.4

[Gergely Nagy]

Balazs Scheidler <bazsi77 at gmail.com> writes:

> ----- Original message -----
>> On 11/17/2012 09:00 AM, Balazs Scheidler wrote:
>> > dbparser: support inheriting properties in a corellation action
>> > 
>> > I merged this one, although I have some doubts. It uses
>> > log_msg_clone_cow(), which does have some tricky semantics, as it
>> > assumes that the cloned message will not change, once cloned.
>> > 
>> > I was thinking about removing clone_cow() completely because of this
>> > tricky stuff, and whenever we need a clone we're about to change the
>> > LogMessage anyway, and delaying the actual change means that we have
>> > to do two malloc() calls, instead of one.
>> > 
>> > Can you test whether changing the message that triggered the action
>> > with a rewrite rule, keeps the cloned one intact? This would need a
>> > parallel path to the db-parser().
>> It seems, that log_msg_clone_cow write protects the original log 
>> message, so trying to do a log_msg_set_value on the original message 
>> will result in an assertion. Sorry I didn't realize this when doing the 
>> original patch, explicitly copying all the name-value pairs seemed 
>> inefficient, but this behaviour is not desirable. Should I rework the 
>> patch this way or is there a better way of doing it?
>> 
>
> I'd drop clone_cow() now, and implement a proper clone that allocates the logmsg header and nvtable in a single block, and copies everything through.
>
> that way clone+change becomes cheaper and you got a clone call that
> works in this case too.

There's another problem, though: pattern_db_process() also sets the
original message write protected, so even if I do a proper clone, the
original will remain write protected.

I'm also a bit confused about the single block header + nvtable
allocation...

I suppose I can do clone = log_msg_alloc(msg->payload->size), copy the
header and the payload too and adjust clone->payload. Is that the
correct way to do it?

-- 
|8]