Re: pg_upgrade automatic testing
От | Andrew Dunstan |
---|---|
Тема | Re: pg_upgrade automatic testing |
Дата | |
Msg-id | 4E6172C3.2080703@dunslane.net обсуждение исходный текст |
Ответ на | Re: pg_upgrade automatic testing (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 09/02/2011 07:49 PM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> On 09/02/2011 06:37 PM, Peter Eisentraut wrote: >>> It won't work, unless you have a solution for fixing the paths of the >>> shared library modules used by the regression tests. >> Well, we could drop those functions and not run tests that require them. >> Or we could possibly install the libraries in $libdir and hack pg_proc >> accordingly. We'd have to install them on both the source and >> destination branches, of course. > The only one that's problematic is pg_regress.so; contrib modules are > already installed in $libdir. I still think that installing > pg_regress.so in $libdir may be the most reasonable solution, assuming > that the delta involved isn't too great. Yeah, we would have to > back-patch the changes into every release branch we want to test > upgrading from, but how risky is that really? The *only* thing it > affects is the regression tests. Agreed. It doesn't seem terribly dangerous. There are three listed in the regression db I just looked at: regress.so, autoinc.so and refint.so. > Maybe I should produce a draft patch for moving pg_regress.so that way, > and we could see how big a delta it really is. Sounds like a plan. cheers andrew
В списке pgsql-hackers по дате отправления: