Thread: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
From
"Kevin Grittner"
Date:
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
Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
From
"Joshua D. Drake"
Date:
On 01/03/2013 02:30 PM, Kevin Grittner wrote: > > 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. Or the data doesn't change that much but in principle I agree with you. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC @cmdpromptinc - 509-416-6579