[HACKERS] Something screwy about OID assignment with WAL code

[Tom Lane]

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