From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
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-18 20:03:38 |
Message-ID: | 3787515.1674072218@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
0001-Don-t-show-bogus-recovery-stop-time.V3.patch | text/x-diff | 852 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Gavan Schneider | 2023-01-18 20:15:23 | Re: Tools for moving normalized data around |
Previous Message | Jeremy Smith | 2023-01-18 20:02:37 | Re: Tools for moving normalized data around |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-01-18 20:15:17 | Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation |
Previous Message | Robert Haas | 2023-01-18 19:51:38 | Re: almost-super-user problems that we haven't fixed yet |