Re: pgbench - use pg logging capabilities

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: pgbench - use pg logging capabilities
Дата
Msg-id alpine.DEB.2.21.2001061050340.24609@pseudo
обсуждение исходный текст
Ответ на Re: pgbench - use pg logging capabilities  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pgbench - use pg logging capabilities
Список pgsql-hackers
Bonjour Michaël,

>> Without looking at the context I thought that argv[0] was the program name,
>> which is not the case here. I put it back everywhere, including the DEBUG
>> message.
>
> The variable names in Command are confusing IMO...

Somehow, yes. Note that there is a logic, it will indeed be the argv of 
the called shell command… And I do not think it is the point of this patch 
to solve this possible confusion.

> +     pg_log_error("gaussian parameter must be at least "
> +                  "%f (not %f)", MIN_GAUSSIAN_PARAM, param);

> I would keep all the error message strings to be on the same line.
> That makes grepping for them easier on the same, and that's the usual
> convention even if these are larger than 72-80 characters.

Ok. I also did other similar cases accordingly.

> #ifdef DEBUG
> Worth removing this ifdef?

Yep, especially as it is the only instance. Done.

> +       pg_log_fatal("unexpected copy in result");
> +       pg_log_error("%s", PQerrorMessage(con));

> +       pg_log_fatal("cannot count number of branches");
> +       pg_log_error("%s", PQerrorMessage(con));

> These are inconsistent with the rest, why not combining both?

Ok, done.

> I think that I would just remove the "debug" variable defined in 
> pgbench.c all together, and switch the messages for the duration and the 
> one in executeMetaCommand to use info-level logging..

Ok, done.

Patch v4 attached addresses all these points.

-- 
Fabien.
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: ALTER TABLE ... SET STORAGE does not propagate to indexes
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)