Thread: Putting OIDs etc back into pg_dump?

There was a recent post on -performance where someone had run 
pg_resetxlog and nuked their transaction counter. Whenever someone has 
filesystem-level problems like this they need to know: - "current" transaction ID - OIDs of system objects

Of course, OIDs have been removed from a standard pg_dump so different 
installations can diff their schemas (and a good thing too).

So - should this information be: 1. Logged nightly via standard logging procedures. 2. Stored in a format=custom dump
butnot for textual schemas. 3. Stored in a different file, that is updated on occasion 4. Not stored at all, it's
pointless.5. Not stored at all, PITR means this is academic now.
 

--   Richard Huxton  Archonet Ltd

> Of course, OIDs have been removed from a standard pg_dump so different 
> installations can diff their schemas (and a good thing too).
> 
> So - should this information be:
>  1. Logged nightly via standard logging procedures.
>  2. Stored in a format=custom dump but not for textual schemas.
>  3. Stored in a different file, that is updated on occasion
>  4. Not stored at all, it's pointless.
>  5. Not stored at all, PITR means this is academic now.

If you dump with oids, it has the latest oid in the dump file...

Chris