From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Do I understand commit timestamps correctly? |
Date: | 2020-05-13 15:28:40 |
Message-ID: | 20200513152840.GA5545@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-May-13, Chapman Flack wrote:
> Getting around to trying it out, simply changing the setting in
> postgresql.conf before starting the server does not seem sufficient:
> once it comes online, it has track_commit_timestamp on, but has not
> populated the cache from transactions it applied during recovery.
Ah. I had not realized that that was what you wanted to do.
> On the other hand, changing the setting in postgresql.conf *and*
> poking a 1 in the track_commit_timestamp byte in pg_control,
> and fudging the CRC accordingly, *then* starting the server, does
> seem to do just as I had hoped. Nothing seems to complain or fall over,
> and the transactions recovered from WAL now have timestamps visible
> with pg_xact_commit_timestamp().
Nice hack. I guess you'd sooner have a supported way to enable the bit
in pg_control. Is there a use case for this?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-05-13 15:28:46 | Re: SLRU statistics |
Previous Message | Alvaro Herrera | 2020-05-13 15:23:57 | Re: Add "-Wimplicit-fallthrough" to default flags |