On 08/27/2014 02:37 PM, Fabien COELHO wrote:
> As for an actual "latency limit" under throttling, this is significantly
> more tricky and invasive to implement... ISTM that it would mean:
>
> - if the tx is not stated an the latency is already consummed, SKIP++.
>
> - if the tx is after its schedule start time but under latency, then
> start it, and maybe inject a "SET TIMEOUT...".
>
> - if a tx is being processed but reaches its latency limit (after
> schedule start time), abort it coldly, ROLLBACK++ (well if the tx is
> really started, there could also be shell commands and \set stuff in a
> pgbench script, which mean started is not really started, so it would
> be INTERRUPT++ if no BEGIN was sent).
>
> - if a tx is finished but the final commit returned after the latency
> deadline, you cannot abort it anymore but it is late nevertheless,
> LATE++.
Yeah, something like that. I don't think it would be necessary to set
statement_timeout, you can inject that in your script or postgresql.conf
if you want. I don't think aborting a transaction that's already started
is necessary either. You could count it as LATE, but let it finish first.
> This is doable but far beyond my current needs. Moreover, I'm not sure
> that such a patch would pass because of invasiveness and complexity, so it
> could be a total loss of time.
>
>> Ok, but *why* are you doing a "lag limit", and not a "latency limit"?
>
> Because it is much simpler (see above) and is enough for testing pg
> responsiveness issue, which is my current objective, and models some
> client timeout behavior.
>
>> Under what circumstances is the lag limit a more useful setting?
>
> It is not "more" useful" per se, it is what I'm using to test pg
> unresponsivness with a simple to define and interpret measure wrt
> throttling.
>
> If I would do "latency limit" under throttling, it would be (1) more time
> to develop, more complex, more invasive in the code (see above, + also the
> implementation when not under throttling), (2) more complex to interpret,
> with at least 5 possible outcomes (skipped, interrupted, committed on
> time, committed but late, aborted), (3) this added information would not
> be useful to me.
>
> I've submitted this "simple" lag limit version because being able to
> measure quickly and simply (un)responsiveness seems like a good idea,
> especially given the current state of things.
Ok, fair enough. I don't think doing a "latency limit" would be
significantly harder, but I can't force you. I'll mark this as Returned
with Feedback then.
- Heikki
