Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Bruce Momjian <bruce@momjian.us>, Peter Eisentraut <peter_e@gmx.net>
Date: 2018-11-05T22:08:12Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2018-11-05 16:32:20 -0500, Tom Lane wrote:
>> It's injected via the TEMP_CONFIG env variable.

> Ah, thanks.  Is there any good reason to not instead have it in the
> script?

Why that script in particular?  If you don't want fsync, you likely
don't want it across the entire check-world run.  The TEMP_CONFIG
thing is a hack no doubt, but it gets the job done globally.  Also,
if you *do* want fsync, there's one place to turn it back on.  I'm
not a fan of individual tests deciding they know what to do.

			regards, tom lane

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.