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 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.

-- 
   Richard Huxton
   Archonet Ltd

Wed, 23 Jun 2004 12:54:56 +0100
Richard Huxton <dev@archonet.com>
Putting OIDs etc back into pg_dump?
> 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


Thu, 24 Jun 2004 10:04:28 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Putting OIDs etc back into pg_dump?