Re: Cleanup isolation specs from unused steps

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Cleanup isolation specs from unused steps
Date: 2019-08-20 13:47:22
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2019-Aug-20, Michael Paquier wrote:
>> On Mon, Aug 19, 2019 at 10:23:19AM -0700, Melanie Plageman wrote:
>>> Could you do the check that all steps have been used in dry_run mode
>>> instead of when running the tests for real?

>> Sure, I was hesitating to do so. I have no issue in moving the check
>> into run_testspec(). So done as attached.

> I created the dry-run mode to be able to easily generate the set of
> possible permutations for a new test, then edit the result and put it
> back in the spec file; but after the deadlock tests were added (with
> necessary hacking of the lock-detection in isolationtester) that manner
> of operation became almost completely useless. Maybe we need to rethink
> what facilities isolationtester offers -- possibly making dry-run have a
> completely different behavior than currently, which I doubt anybody is
> using.

Hm, does that mean that this version of the patch would fail to warn
during a normal run? Doesn't sound good, since as Alvaro says,
hardly anyone uses dry-run.

If you can warn in both cases, that'd be OK perhaps. But Alvaro's
description of the intended use of dry-run makes it sound like
it would be expected for there to be unreferenced steps, since there'd
be no permutations yet in the input.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-08-20 13:54:56 Re: Cleanup isolation specs from unused steps
Previous Message Anastasia Lubennikova 2019-08-20 13:38:18 Re: pg_upgrade fails with non-standard ACL