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-18 08:27:02 |
Message-ID: | d0af6fef161cf9a161f2b9377193b9099e73d17e.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
> 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.)
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
Attachment | Content-Type | Size |
---|---|---|
0001-Don-t-show-bogus-recovery-stop-time.V2.patch | text/x-patch | 2.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2023-01-18 10:02:16 | Re: Are ZFS snapshots unsafe when PGSQL is spreading through multiple zpools? |
Previous Message | Adrian Klaver | 2023-01-18 05:27:42 | Re: Tablespace OID, database OID, relfilenode |
From | Date | Subject | |
---|---|---|---|
Next Message | Nikita Malakhov | 2023-01-18 08:27:19 | Re: Inconsistency in vacuum behavior |
Previous Message | wangw.fnst@fujitsu.com | 2023-01-18 08:19:08 | RE: Logical replication timeout problem |