Re: Avoid stuck of pbgench due to skipped transactions

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: Raw Message | Whole Thread | Download mbox | Resend email
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.


In response to


Browse pgsql-hackers by date

  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