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 |
Message-ID: | 5052.1566308842@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
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 |