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: | [email protected] |
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
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 |