Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Date
Msg-id alpine.DEB.2.21.1808171302510.20841@lancre
Whole thread Raw
In response to Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors  (Marina Polyakova <m.polyakova@postgrespro.ru>)
Responses Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
List 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 by date:

Previous
From: Fabien COELHO
Date:
Subject: libpq stricter integer parsing
Next
From: Marina Polyakova
Date:
Subject: Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors