Horton

Re: Why do pg_upgrade's test use the serial schedule?

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Bruce Momjian <bruce@momjian.us>
Date: 2018-11-07T07:16:04Z
Lists: pgsql-hackers 
On 05/11/2018 22:00, Andres Freund wrote:
> The test I'm most commonly waiting for when doing a parallel make check
> is pg_upgrade. And to a significant degree that's because it uses the
> serial installcheck rather than installcheck-parallel.
> 
> Is there a reason to not use installcheck-parallel?

Probably worth trying.  Using serial was probably just the conservative
choice at the time.

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

Commits

  1. Make TupleTableSlots extensible, finish split of existing slot type.

  2. Inline hot path of slot_getsomeattrs().

  3. Compute information about EEOP_*_FETCHSOME at expression init time.

  4. Don't generate tuple deforming functions for virtual slots.

  5. Introduce notion of different types of slots (without implementing them).

  6. Verify that expected slot types match returned slot types.

  7. Rejigger materializing and fetching a HeapTuple from a slot.

  8. Rationalize expression context reset in ExecModifyTable().

  9. Don't require return slots for nodes without projection.

  10. Move EEOP_*_SYSVAR evaluation out of line.

  11. Use installcheck-parallel in pg_upgrade's testsuite.