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:
Robert Haas wrote: > Christopher Browne <cbbrowne@gmail.com> wrote: >> these timestamps Should Not be captured or carried forward by >> pg_dump. >> If we put a creation time into pg_database or pg_class, then >> streaming replication will, as a "physical" replication >> mechanism, carry the timestamp forward into replicas >> And in contrast, I'd expect Andres Freund's logical replication >> infrastructure *NOT* to carry these dates over, but rather to >> establish fresh new creation dates on a replica. (And from a >> forensic perspective, that's a perfectly fine thing.) > > I agree all around. +1 My analogy would be to xmin in tuples. Anything that preserves that should preserve table creation timestamp. If the tuples' xmin values in the table receiving the data differ, the creation timestamp should, too. In my experience, this would have been valuable forensic information many times. Preserving xmin rather than aggressively freezing never has been or would have been useful to me. -Kevin
Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
From
Andrew Dunstan
Date:
On 01/03/2013 04:51 PM, Kevin Grittner wrote: > Robert Haas wrote: >> Christopher Browne <cbbrowne@gmail.com> wrote: >>> these timestamps Should Not be captured or carried forward by >>> pg_dump. >>> If we put a creation time into pg_database or pg_class, then >>> streaming replication will, as a "physical" replication >>> mechanism, carry the timestamp forward into replicas >>> And in contrast, I'd expect Andres Freund's logical replication >>> infrastructure *NOT* to carry these dates over, but rather to >>> establish fresh new creation dates on a replica. (And from a >>> forensic perspective, that's a perfectly fine thing.) >> I agree all around. > +1 > > My analogy would be to xmin in tuples. Anything that preserves that > should preserve table creation timestamp. If the tuples' xmin > values in the table receiving the data differ, the creation > timestamp should, too. > > In my experience, this would have been valuable forensic > information many times. Preserving xmin rather than aggressively > freezing never has been or would have been useful to me. > 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. cheers andrew