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.
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 |