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
>
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 |