| From: | "Kevin Grittner" <kgrittn(at)mail(dot)com> |
|---|---|
| To: | "Robert Haas" <robertmhaas(at)gmail(dot)com>,"Christopher Browne" <cbbrowne(at)gmail(dot)com> |
| Cc: | "Hannu Krosing" <hannu(at)2ndquadrant(dot)com>,"Stephen Frost" <sfrost(at)snowman(dot)net>, "Andres Freund" <andres(at)2ndquadrant(dot)com>, "Dimitri Fontaine" <dimitri(at)2ndquadrant(dot)fr>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Josh Berkus" <josh(at)agliodbs(dot)com>,pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database" |
| Date: | 2013-01-03 21:51:02 |
| Message-ID: | 20130103215103.4840@gmx.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas wrote:
> Christopher Browne <cbbrowne(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2013-01-03 22:11:28 | Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database" |
| Previous Message | Josh Berkus | 2013-01-03 21:15:17 | Re: Reminder: CFP for pgCon closes January 19th |