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-17 15:32:50 |
Message-ID: | 2964581.1673969570@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 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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Wiwwo Staff | 2023-01-17 15:35:53 | Re: Tablespace OID, database OID, relfilenode |
Previous Message | HECTOR INGERTO | 2023-01-17 15:22:02 | RE: Are ZFS snapshots unsafe when PGSQL is spreading through multiple zpools? |
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2023-01-17 15:53:27 | Re: Issue attaching a table to a partitioned table with an auto-referenced foreign key |
Previous Message | Robert Haas | 2023-01-17 15:26:52 | Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation |