Prior to this change probably it was working not properly in 100% of cases
(timestamp was updated even if prepared transaction wasn't committed yet?),
but still it was a good way to check replication delay and it worked. Now
pg_last_xact_replay_timestamp() is useless for such purpose and I hope you
can fix this in next minor release.
--
Sergiy Zuban
On Thu, Jul 24, 2014 at 4:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> s.zuban@gmail.com writes:
> > After upgrade from 9.3.4 to 9.3.5 pg_last_xact_replay_timestamp() returns
> > outdated timestamp.
>
> > It stopped working properly after commit
> > d19bd29f07aef9e508ff047d128a4046cc8bc1e2
>
> Really?
>
> It looks to me like this never worked: the code around recoveryStopsHere
> has never paid any attention to COMMIT_PREPARED (or ABORT_PREPARED).
> Certainly that patch had zip to do with the replay-timestamp behavior.
>
> If you think it worked before, I'd like to see what your test case was.
>
> regards, tom lane
>