Re: pgbench stats per script & other stuff - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench stats per script & other stuff
Date
Msg-id alpine.DEB.2.10.1603041943110.11128@sto
Whole thread Raw
In response to Re: pgbench stats per script & other stuff  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pgbench stats per script & other stuff
Re: pgbench stats per script & other stuff
List pgsql-hackers
>> That is why the "fs" variable in process_file is declared "static", and why
>> I wrote "some hidden awkwarness".
>>
>> I did want to avoid a malloc because then who would free the struct?
>> addScript cannot to it systematically because builtins are static. Or it
>> would have to create an on purpose struct, but I then that would be more
>> awkwarness, and malloc/free to pass arguments between functions is not
>> efficient nor very elegant.
>>
>> So the "static" option looked like the simplest & most elegant version.
>
> Surely that trick breaks if you have more than one -f switch, no?  Oh, I
> see what you're doing: you only use the command list, which is
> allocated, so it doesn't matter that the rest of the struct changes
> later.

The two fields that matter (desc and commands) are really copied into 
sql_scripts, so what stays in the is overriden if used another time.

> I'm not concerned about freeing the struct; what's the problem with it
> surviving until the program terminates?

It is not referenced anywhere so it is a memory leak.

> If somebody specifies thousands of -f switches, they will waste a few 
> bytes with each, but I'm hardly concerned about a few dozen kilobytes 
> there ...

Ok, so you prefer a memory leak. I hate it on principle.

Here is a v23 with a memory leak anyway.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pgbench small bug fix
Next
From: Robert Haas
Date:
Subject: Re: Logic problem in SerializeSnapshot()