Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Дата
Msg-id alpine.DEB.2.21.1808101027390.9120@lancre
обсуждение исходный текст
Ответ на Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors  (Marina Polyakova <m.polyakova@postgrespro.ru>)
Ответы Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors  (Marina Polyakova <m.polyakova@postgrespro.ru>)
Список pgsql-hackers
Hello Marina,

>> I'd suggest to let lookupCreateVariable, putVariable* as they are,
>> call pgbench_error with a level which does not stop the execution, and
>> abort if necessary from the callers with a "aborted because of
>> putVariable/eval/... error" message, as it was done before.
>
> There's one more problem: if this is a client failure, an error message 
> inside any of these functions should be printed at the level DEBUG_FAILS; 
> otherwise it should be printed at the level LOG. Or do you suggest using the 
> error level as an argument for these functions?

No. I suggest that the called function does only one simple thing, 
probably "DEBUG", and that the *caller* prints a message if it is unhappy 
about the failure of the called function, as it is currently done. This 
allows to provide context as well from the caller, eg "setting variable %s 
failed while <some specific context>". The user call rerun under debug for 
precision if they need it.

I'm still not over enthousiastic with these changes, and still think that 
it should be an independent patch, not submitted together with the "retry 
on error" feature.

-- 
Fabien.


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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench's expression parsing & negative numbers
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: xact_start meaning when dealing with procedures?