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

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.

In response to

Responses

Browse pgsql-hackers by date

  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