| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> | 
|---|---|
| To: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Avoid stuck of pbgench due to skipped transactions | 
| Date: | 2021-06-14 06:47:40 | 
| Message-ID: | alpine.DEB.2.22.394.2106140830320.1338009@pseudo | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
>>> I attached a patch for this fix.
>>
>> The patch mostly works for me, and I agree that the bench should not be in
>> a loop on any parameters, even when "crazy" parameters are given…
>>
>> However I'm not sure this is the right way to handle this issue.
>>
>> The catch-up loop can be dropped and the automaton can loop over itself to
>> reschedule. Doing that as the attached fixes this issue and also makes
>> progress reporting work proprely in more cases, and reduces the number of
>> lines of code. I did not add a test case because time sensitive tests have
>> been removed (which is too bad, IMHO).
>
> I agree with your way to fix. However, the progress reporting didn't work
> because we cannot return from advanceConnectionState to threadRun and just
> break the loop.
>
> +						/* otherwise loop over PREPARE_THROTTLE */
> 						break;
>
> I attached the fixed patch that uses return instead of break, and I confirmed
> that this made the progress reporting work property.
I'm hesitating to do such a strictural change for a degenerate case linked 
to "insane" parameters, as pg is unlikely to reach 100 million tps, ever.
It seems to me enough that the command is not blocked in such cases.
-- 
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-06-14 06:48:13 | Re: Fix dropped object handling in pg_event_trigger_ddl_commands | 
| Previous Message | Tom Lane | 2021-06-14 06:40:53 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |