From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Torsten Förtsch <tfoertsch123(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: minor bug |
Date: | 2023-01-19 12:57:14 |
Message-ID: | 4ae9feb22332aca790968b550f0016a1f97c3739.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Wed, 2023-01-18 at 15:03 -0500, Tom Lane wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
> > > I seem to recall that the original idea was to report the timestamp
> > > of the commit/abort record we are stopping at. Maybe my memory is
> > > faulty, but I think that'd be significantly more useful than the
> > > current behavior, *especially* when the replay stopping point is
> > > defined by something other than time.
> > > (Also, the wording of the log message suggests that that's what
> > > the reported time is supposed to be. I wonder if somebody messed
> > > this up somewhere along the way.)
>
> > recoveryStopTime is set to recordXtime (the time of the xlog record)
> > a few lines above that patch, so this is useful information if it is
> > present.
>
> Ah, but that only happens if recoveryTarget == RECOVERY_TARGET_TIME.
> Digging in the git history, I see that this did use to work as
> I remember: we always extracted the record time before printing it.
> That was accidentally broken in refactoring in c945af80c. I think
> the correct fix is more like the attached.
Yes, you are right. Your patch looks fine to me.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Torsten Förtsch | 2023-01-19 17:18:04 | Re: minor bug |
Previous Message | Harmen | 2023-01-19 09:04:25 | Re: row estimate for partial index |
From | Date | Subject | |
---|---|---|---|
Next Message | tushar | 2023-01-19 12:58:02 | Re: almost-super-user problems that we haven't fixed yet |
Previous Message | Laurenz Albe | 2023-01-19 12:50:05 | Re: document the need to analyze partitioned tables |