Re: Read Uncommitted regression test coverage - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Read Uncommitted regression test coverage
Date
Msg-id 02bd8490-611e-043c-747c-031de5d15302@gmail.com
Whole thread Raw
In response to Re: Read Uncommitted regression test coverage  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 12/18/19 2:17 PM, Tom Lane wrote:
> Mark Dilger <hornschnorter@gmail.com> writes:
>>> The one in src/test/isolation doesn't look very comprehensive.  I'd
>>> at least expect a test that verifies you don't get a syntax error
>>> when you request READ UNCOMMITTED isolation from SQL.
> 
>> The attached patch set adds a modicum of test coverage for this.
>> Do others feel these tests are worth the small run time overhead
>> they add?
> 
> No.  As you pointed out yourself, READ UNCOMMITTED is the same as READ
> COMMITTED, so there's hardly any point in testing its semantic behavior.
> One or two tests that check that it is accepted by the grammar seem
> like plenty (and even there, what's there to break?  If bison starts
> failing us to that extent, we've got bigger problems.)

The lack of testing in the current system is so complete that if you
go into gram.y and remove READ UNCOMMITTED from the grammar, not one
test in check-world fails.

Somebody doing something like what Simon is suggesting might refactor
the code in a way that unintentionally breaks this isolation level, and
we'd not know about it until users started complaining.

The attached patch is pretty cheap.  Perhaps you'll like it better?

-- 
Mark Dilger

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Michael Paquier
Date:
Subject: Re: automating pg_config.h.win32 maintenance