Something screwy about OID assignment with WAL code

Current sources pass regress test except for

*** ./expected/opr_sanity.out    Mon Nov 13 22:59:14 2000
--- ./results/opr_sanity.out    Mon Nov 20 17:12:50 2000
***************
*** 481,489 ****      NOT ((p2.pronargs = 2 AND p1.aggbasetype = p2.proargtypes[1]) OR           (p2.pronargs = 1 AND
p1.aggbasetype= 0)));   oid  | aggname | oid |   proname   
 
! -------+---------+-----+-------------
!  16998 | max     | 768 | int4larger
!  17012 | min     | 769 | int4smaller (2 rows)  -- Cross-check finalfn (if present) against its entry in pg_proc.
--- 481,489 ----      NOT ((p2.pronargs = 2 AND p1.aggbasetype = p2.proargtypes[1]) OR           (p2.pronargs = 1 AND
p1.aggbasetype= 0)));  oid  | aggname | oid |   proname   
 
! ------+---------+-----+-------------
!  2523 | max     | 768 | int4larger
!  2537 | min     | 769 | int4smaller (2 rows)  -- Cross-check finalfn (if present) against its entry in pg_proc.

Further investigation shows

template1=# select min(oid),max(oid) from pg_aggregate;min  | max
------+------2503 | 2558
(1 row)

This is bogus.  The pg_aggregate entries should have OIDs above
16384, not down in the reserved-OID range.  It looks to me like
initial startup of the OID counter is wrong with WAL enabled.
        regards, tom lane