Re: 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: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: WIP Patch: Pgbench Serialization and deadlock errors
Date: 2018-01-12 15:13:52
Message-ID: alpine.DEB.2.20.1801121607310.13422@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Marina,

>> If you want 2 transactions, then you have to put them in two scripts,
>> which looks fine with me. Different transactions are expected to be
>> independent, otherwise they should be merged into one transaction.
>
> Therefore if the script consists of several single statements (= several
> transactions), you cannot retry them. For example, the script looked like
> this:
>
> UPDATE xy1 SET x = 1 WHERE y = 1;
> UPDATE xy2 SET x = 2 WHERE y = 2;
> UPDATE xy3 SET x = 3 WHERE y = 3;
>
> If this restriction is ok for you, I'll simplify the code :)

Yes, that is what I'm suggesting. If you want to restart them, you can put
them in 3 scripts.

>> Under these restrictions, ISTM that a retry is something like:
>>
>> case ABORTED:
>> if (we want to retry) {
>> // do necessary stats
>> // reset the initial state (random, vars, current command)
>> state = START_TX; // loop
>> }
>> else {
>> // count as failed...
>> state = FINISHED; // or done.
>> }
>> break;
>
> If we successfully complete a failed transaction block and process its end
> command in CSTATE_END_COMMAND, we may want to make a retry. So do you think
> that in this case it is ok to go to CSTATE_ABORTED at the end of
> CSTATE_END_COMMAND?..

Dunno.

I'm fine with having END_COMMAND skipping to START_TX if it can be done
easily and cleanly, esp without code duplication.

ISTM that ABORTED & FINISHED are currently exactly the same. That would
put a particular use to aborted. Also, there are many points where the
code may go to "aborted" state, so reusing it could help avoid duplicating
stuff on each abort decision.

>> Once this works, maybe it could go a step further by restarting at
>> savepoints. I'd put restrictions there to ease detecting a savepoint
>> so that it cannot occur in a compound command for instance. This would
>> probably require a new state. Fine.
>
> We discussed the savepoints earlier in [1]:

Yep. I'm trying to suggest an incremental path with simple but yet quite
useful things first.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marina Polyakova 2018-01-12 15:15:25 Re: master make check fails on Solaris 10
Previous Message Alvaro Herrera 2018-01-12 15:12:54 Re: master make check fails on Solaris 10