[HACKERS] Putting OIDs etc back into pg_dump?

[Richard Huxton]

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
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Putting OIDs etc back into pg_dump?

[Christopher Kings-Lynne]

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
---(end of broadcast)---
TIP 8: explain analyze is your friend