Re: tracking commit timestamps - Mailing list pgsql-hackers

From Robert Haas
Subject Re: tracking commit timestamps
Date
Msg-id CA+TgmoZcR9zo55mjTgTuPSQPREUqqn4oY9Jt8qy24c_7-KFQow@mail.gmail.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Wed, Nov 19, 2014 at 8:22 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Petr Jelinek wrote:
>> This is good point, we are not too late in the cycle that LSN couldn't be
>> added later if we find that it is indeed needed (and we don't have to care
>> about pg_upgrade until beta).
>
> I think we're overblowing the pg_upgrade issue.  Surely we don't need to
> preserve commit_ts data when upgrading across major versions; and
> pg_upgrade is perfectly prepared to remove old data when upgrading
> (actually it just doesn't copy it; consider pg_subtrans or pg_serial,
> for instance.)  If we need to change binary representation in a future
> major release, we can do so without any trouble.

Actually, that's a good point.  I still don't understand what the
resistance is to add something quite inexpensive that multiple people
obviously want, but at least if we don't, we still have the option to
change it later.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Next
From: Robert Haas
Date:
Subject: Re: Add shutdown_at_recovery_target option to recovery.conf