Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Bruce Momjian <bruce@momjian.us>, Peter Eisentraut <peter_e@gmx.net>
Date: 2018-11-06T00:24:57Z
Lists: pgsql-hackers 
On Mon, Nov 05, 2018 at 02:11:42PM -0800, Andres Freund wrote:
> Because just about everything else taking substantial time already
> disables it. pg_regress forks off a postmaster with -F, the tap tests do
> so for large portions via fsync=off in the config (c.f. PostgresNode.pm).

And in most cases people will forget to set up TEMP_CONFIG when setting
up a new environment.  If it is possible to reduce the I/O traffic when
running check-world by default and if we are able to make it faster with
a parallel schedule, my take is to do by default instead of expecting
the user to set up that all the time.  That's less to think about.

So I am +1 and +1 for Andres' suggestions on this thread.
--
Michael

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.