Re: minor bug
Laurenz Albe <laurenz.albe@cybertec.at>
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Torsten Förtsch <tfoertsch123@gmail.com>, pgsql-hackers@postgresql.org, Michael Paquier <michael@paquier.xyz>
Date: 2023-01-18T08:27:02Z
Lists: pgsql-hackers, pgsql-general
Attachments
- 0001-Don-t-show-bogus-recovery-stop-time.V2.patch (text/x-patch) patch 0001
On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote: > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > On Mon, 2023-01-16 at 19:59 +0100, Torsten Förtsch wrote: > > > So, the timestamp displayed in the log message is certainly wrong. > > > If recovery stops at a WAL record that has no timestamp, you get this > > bogus recovery stop time. I think we should show the recovery stop time > > only if time was the target, as in the attached patch. > > I don't think that is a tremendously useful definition: the user > already knows what recoveryStopTime is, or can find it out from > their settings easily enough. > > 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. I realized that my original patch might be a problem for translation; here is an updated version that does not take any shortcuts. Yours, Laurenz Albe
Commits
-
Log the correct ending timestamp in recovery_target_xid mode.
- abe203304e15 15.2 landed
- 87591db1918a 12.14 landed
- 44e9e34266ef 16.0 landed
- 1b9a0b96a870 13.10 landed
- 103450724557 14.7 landed
- 0a269527f6a1 11.19 landed