On Thu, Feb 8, 2018 at 12:13 AM, Claudio Freire <klaussfre...@gmail.com> wrote: > On Wed, Feb 7, 2018 at 11:29 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: >> Claudio Freire wrote: >>> On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> >>> wrote: >>> >> Waiting as you say would be akin to what the patch does by putting >>> >> vacuum on its own parallel group. >>> > >>> > I don't think it's the same. We don't need to wait until all the >>> > concurrent tests are done -- we only need to wait until the transactions >>> > that were current when the delete finished are done, which is very >>> > different since each test runs tons of small transactions rather than >>> > one single big transaction. >>> >>> Um... maybe "lock pg_class" ? >> >> I was thinking in first doing >> SELECT array_agg(DISTINCT virtualtransaction) vxids >> FROM pg_locks \gset >> >> and then in a DO block loop until >> >> SELECT DISTINCT virtualtransaction >> FROM pg_locks >> INTERSECT >> SELECT (unnest(:'vxids'::text[])); >> >> returns empty; something along those lines. > > Isn't it the same though? > > I can't think how a transaction wouldn't be holding at least an access > share on pg_class.
Never mind, I just saw the error of my ways. I don't like looping, though, seems overly cumbersome. What's worse? maintaining that fragile weird loop that might break (by causing unexpected output), or a slight slowdown of the test suite? I don't know how long it might take on slow machines, but in my machine, which isn't a great machine, while the vacuum test isn't fast indeed, it's just a tiny fraction of what a simple "make check" takes. So it's not a huge slowdown in any case. I'll give it some thought, maybe there's a simpler way.
