From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, 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-11 16:09:07 |
Message-ID: | 20160511160907.GA694787@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
> On 5/3/16 1:25 PM, Alvaro Herrera wrote:
> >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.
>
> Not that that would be useless, but note that the value in this case (and
> most others) comes from having a candidate object in the database before
> upgrade that exercises the particular problem, mostly independent of what
> version you upgrade from and to. So far the way to do that is to leave
> "junk" in the regression test database, but that's clearly a bit silly.
True. We have quite a few places in the standard regression tests that
leave junk behind purposefully for this reason.
> I think the way forward is to create a TAP test suite for pg_upgrade that
> specifically exercises a lot of scenarios with small purpose-built test
> databases.
That works for me.
> Then, the problem of having to compare dump output across versions also goes
> away more easily.
Not sure why, but if you think it does, then it sounds good. Andrew's
current approach of counting lines in the diff seems brittle and not
entirely trustworthy.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-05-11 16:19:28 | Re: asynchronous and vectorized execution |
Previous Message | Andres Freund | 2016-05-11 15:49:39 | Re: asynchronous and vectorized execution |