Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore

From: Sergiy Zuban <s(dot)zuban(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore
Date: 2014-07-25 15:21:26
Message-ID: CAGz8fGYbAZVnf=3GWAVEmkCm56EWkk2nA=ozkdwFic2h6Rdy1g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> s(dot)zuban(at)gmail(dot)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
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Lars Ewald (web.de) 2014-07-25 19:59:56 Re: Fwd: Re: Compile fails on AIX 6.1
Previous Message David G Johnston 2014-07-25 13:38:40 Re: BUG #11031: Unexpected interval representations