Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
От | Andrew Dunstan |
---|---|
Тема | Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database" |
Дата | |
Msg-id | 50E60210.9000002@dunslane.net обсуждение исходный текст |
Ответ на | Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database" ("Kevin Grittner" <kgrittn@mail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: