Re: [CORE] Restore-reliability mode

Michael Paquier wrote:
> On Fri, Jun 5, 2015 at 8:53 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> > In terms of specific testing improvements, things I think we need to have
> > covered and runnable on the buildfarm are:
> >
> > * pg_dump and pg_restore testing (because it's scary we don't do this)
>
> We do test it in some way with pg_upgrade using set of objects that
> are not removed by the regression test suite. Extension dumps are
> uncovered yet though.

We could put more emphasis on having objects of all kinds remain in the
regression database, so that the pg_upgrade test covers more of this.

What happened with the extension tests patches you submitted? They
seemed valuable to me, but I lost track.

> > * DDL deparse test coverage for all operations
>
> What do you have in mind except what is already in objectaddress.sql
> and src/test/modules/test_dll_deparse/?

The current SQL scripts in that test do not cover all possible object
types, so there's a lot of the decoding capabilities that are currently
not exercised. So one way to attack this would be to add more object
types to those files. However, a completely different way is to have
the test process serial_schedule from src/test/regress and run
everything in there under deparse. That would be even more useful,
because whenever some future DDL is added, we will automatically get
coverage.

> > How would a test that would've caught the multixact issues look?
>
> I have not followed closely those discussions, not sure about that.

One issue with these bugs is that unless you use things such as
pg_burn_multixact, producing large enough numbers of multixacts takes a
long time. I've wondered if we could somehow make those easier to
reproduce by lowering the range, and thus doing thousands of
wraparounds, freezing and truncations in reasonable time. (For example,
change the typedefs to uint16 rather than uint32). But then the issue
becomes that the test code is not exactly equivalent to the production
code, which could cause its own bugs.

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