Re: Add an optional timeout clause to isolationtester step.

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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.
Date: 2020-03-10 02:55:36
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Mon, Mar 09, 2020 at 10:32:27PM -0400, Tom Lane wrote:
> 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.

Interesting idea. So that would be basically an equivalent of
PostgresNode::poll_query_until but for the isolation tester? In short
we gain a meta-command that runs a SELECT query that waits until the
query defined in the command returns true. The polling interval may
be tricky to set though. If set too low it would consume resources
for nothing, and if set too large it would make the tests using this
meta-command slower than they actually need to be. Perhaps something
like 100ms may be fine..

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2020-03-10 03:09:24 Re: Berserk Autovacuum (let's save next Mandrill)
Previous Message Kyotaro Horiguchi 2020-03-10 02:47:42 Re: bad logging around broken restore_command