From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: ALTER TABLE lock downgrades have broken pg_upgrade |
Date: | 2016-05-03 17:25:41 |
Message-ID: | 20160503172541.GA31942@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost wrote:
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> > Tom Lane wrote:
> >
> > > More generally, though, I wonder how we can have some test coverage
> > > on such cases going forward. Is the patch below too ugly to commit
> > > permanently, and if so, what other idea can you suggest?
> >
> > I suggest a buildfarm animal running a custom buildfarm module that
> > exercises the pg_upgrade test from every supported version to the latest
> > stable and to master -- together with your proposed case that leaves a
> > toastless table around for pg_upgrade to handle.
>
> That would help greatly with pg_dump test coverage as well.. One of the
> problems of trying to get good LOC coverage of pg_dump is that a *lot*
> of the code is version-specific...
If we can put together a script that runs test.sh for various versions
and then verifies the runs, we could use it in both buildfarm and
coverage.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2016-05-03 17:28:26 | Re: ALTER TABLE lock downgrades have broken pg_upgrade |
Previous Message | Stephen Frost | 2016-05-03 17:21:53 | Re: ALTER TABLE lock downgrades have broken pg_upgrade |