|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Add an optional timeout clause to isolationtester step.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, Mar 09, 2020 at 03:15:58PM -0700, Andres Freund wrote:
>> That kind of thing can already be done using statement_timeout or
>> lock_timeout, no?
> Yep, still that's not something I would recommend to commit in the
> tree as that's a double-edged sword as you already know. For slower
> machines, you need a statement_timeout large enough so as you make
> sure that the state you want the query to wait for is reached, which
> has a cost on all other faster machines as it makes the tests slower.
It strikes me to wonder whether we could improve matters by teaching
isolationtester to watch for particular values in a connected backend's
pg_stat_activity.wait_event_type/wait_event columns. Those columns
didn't exist when isolationtester was designed, IIRC, so it's not
surprising that they're not used in the current design. But we could
use them perhaps to detect that a backend has arrived at some state
that's not a heavyweight-lock-wait state.
regards, tom lane
|Next Message||Fujii Masao||2020-03-10 02:36:13||Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side|
|Previous Message||Michael Paquier||2020-03-10 02:23:13||Re: Proposal: Add more compile-time asserts to expose inconsistencies.|