Re: pgbench stats per script & other stuff
От | Fabien COELHO |
---|---|
Тема | Re: pgbench stats per script & other stuff |
Дата | |
Msg-id | alpine.DEB.2.10.1603041943110.11128@sto обсуждение исходный текст |
Ответ на | Re: pgbench stats per script & other stuff (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: pgbench stats per script & other stuff
Re: pgbench stats per script & other stuff |
Список | 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 по дате отправления: