Re: coverage increase for worker_spi - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: coverage increase for worker_spi
Date
Msg-id 20190530142215.GA12101@alvherre.pgsql
Whole thread Raw
In response to Re: coverage increase for worker_spi  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: coverage increase for worker_spi  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: coverage increase for worker_spi  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 2019-May-29, Tom Lane wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Tom pointed out that coverage for worker_spi is 0%.  For a module that
> > only exists to provide coverage, that's pretty stupid.  This patch
> > increases coverage to 90.9% line-wise and 100% function-wise, which
> > seems like a sufficient starting point.
> 
> > How would people feel about me getting this in master at this point in
> > the cycle, it being just some test code?  We can easily revert if
> > it seems too unstable.
> 
> I'm not opposed to adding a new test case at this point in the cycle,
> but as written this one seems more or less guaranteed to fail under
> load.

True.  Here's a version that should be more resilient.

One thing I noticed while writing it, though, is that worker_spi uses
the postgres database, instead of the contrib_regression database that
was created for it.  And we create a schema and a table there.  This is
going to get some eyebrows raised, I think, so I'll look into fixing
that as a bugfix before getting this commit in.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Server crash due to assertion failure inCheckOpSlotCompatibility()
Next
From: DEV_OPS
Date:
Subject: Re: Zedstore - compressed in-core columnar storage