From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Subject: | Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors |
Date: | 2018-08-17 11:04:56 |
Message-ID: | alpine.DEB.2.21.1808171302510.20841@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Marina Polyakova | 2018-08-17 11:27:19 | Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors |
Previous Message | Fabien COELHO | 2018-08-17 10:13:12 | libpq stricter integer parsing |