Andrew Dunstan wrote:
> I don't especially have a horse in the race, but ISTM that if you want
> the information you want it to be able to persist across dump/restore,
> at least optionally. If you can happily lose it when you're forced to
> recover using a logical dump then it's not that important to you.
On that point I guess we will just disagree. In my experience, if
you are OK with a periodic pg_dump for your primary backup
technique, then the data is just not that important to you. And if
you drop and re-create a table from pg_dump output, that event is
worth noting -- I would rather see the timestamp of applying the
pg_dump output.
When it comes to forensics, why don't we feel that it is worth
preserving next available xid and every tuple's xmin and xmax
through pg_dump? I don't think we should, but the arguments against
trying to do it seem similar to me. They are newly created tables
when you run the SQL generated by pg_dump, with fresh rows and
indexes. To pretend otherwise seems to me to reduce the value of
the feature.
On the other hand, having one central way to deal with it for all
object types seems to increase the value of the feature.
-Kevin
