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