=?UTF-8?Q?Torsten_F=C3=B6rtsch?= writes:
> Why not
> (void)getRecordTimestamp(record, &recordXtime);
> if (recoveryTarget == RECOVERY_TARGET_TIME)
> ...
Could've done it like that, but I already pushed the other
version, and I don't think it's worth the trouble to change.
Laurenz Albe writes:
> On Wed, 2023-01-18 at 15:03 -0500, Tom Lane wrote:
>> 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 acc
If we never expect getRecordTimestamp to fail, then why put it in the
if-condition?
getRecordTimestamp can fail if the record is not a restore point nor a
commit or abort record. A few lines before in the same function there is
this:
/* Otherwise we only consider stopping before COMMIT or ABORT
On Wed, 2023-01-18 at 15:03 -0500, Tom Lane wrote:
> Laurenz Albe 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 th
Laurenz Albe 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 beha
On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
> Laurenz Albe 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 re
Laurenz Albe 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
On Tue, Jan 17, 2023 at 10:42:03AM +0100, Laurenz Albe wrote:
> 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.
Good catch! I'll try to take a
On Mon, 2023-01-16 at 19:59 +0100, Torsten Förtsch wrote:
> not sure if this is known behavior.
>
> Server version is 14.6 (Debian 14.6-1.pgdg110+1).
>
> In a PITR setup I have these settings:
>
> recovery_target_xid = '852381'
> recovery_target_inclusive = 'false'
>
> In the log file I see thi
