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.1808171302510.20841@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
|
Список | pgsql-hackers |
>>>> commandFailed: I'm not thrilled by the added boolean, which is partially >>>> redundant with the second argument. >>> >>> Do you mean that it is partially redundant with the argument "cmd" and, >>> for example, the meta commands errors always do not cause the abortions of >>> the client? >> >> Yes. And also I'm not sure we should want this boolean at all. > > Perhaps we can use a separate function to print the messages about client's > abortion, something like this (it is assumed that all abortions happen when > processing SQL commands): > > static void > clientAborted(CState *st, const char *message) Possibly. > Or perhaps we can use a more detailed failure status so for each type of > failure we always know the command name (argument "cmd") and whether the > client is aborted. Something like this (but in comparison with the first > variant ISTM overly complicated): I agree., I do not think that it would be useful given that the same thing is done on all meta-command error cases in the end. -- Fabien.
В списке pgsql-hackers по дате отправления: