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

From: Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, 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-07-12 09:15:42
Message-ID: f153ffd55f481d714ee44afc99ecc67e@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11-07-2018 22:34, Fabien COELHO wrote:
>> can we try something like this?
>>
>> PGBENCH_ERROR_START(DEBUG_FAIL)
>> {
>> PGBENCH_ERROR("client %d repeats the failed transaction (try %d",
>
> Argh, no? I was thinking of something much more trivial:
>
> pgbench_error(DEBUG, "message format %d %s...", 12, "hello world");
>
> If you really need some complex dynamic buffer, and I would prefer
> that you avoid that, then the fallback is:
>
> if (level >= DEBUG)
> {
> initPQstuff(&msg);
> ...
> pgbench_error(DEBUG, "fixed message... %s\n", msg);
> freePQstuff(&msg);
> }
>
> The point is to avoid building the message with dynamic allocation and
> so
> if in the end it is not used.

Ok! About avoidance - I'm afraid there's one more piece of debugging
code with the same problem:

else if (command->type == META_COMMAND)
{
...
initPQExpBuffer(&errmsg_buf);
printfPQExpBuffer(&errmsg_buf, "client %d executing \\%s",
st->id, argv[0]);
for (i = 1; i < argc; i++)
appendPQExpBuffer(&errmsg_buf, " %s", argv[i]);
appendPQExpBufferChar(&errmsg_buf, '\n');
ereport(ELEVEL_DEBUG, (errmsg("%s", errmsg_buf.data)));
termPQExpBuffer(&errmsg_buf);

--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-07-12 09:21:21 Re: no partition pruning when partitioning using array type
Previous Message Pavel Stehule 2018-07-12 09:12:59 Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan