Re: Make unlogged table resets detectable

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jun 7, 2021 at 11:46 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
>>> +1. I'd support recording the time of the last crash recovery, as
>>> well as having a counter. I think an LSN would not be as useful
>>> as a timestamp.

>> One could guess a timestamp based on a LSN, no? So I'd like to think
>> the opposite actually: a LSN would be more useful than a timestamp.

> One could also guess an LSN based on a timestamp, but I think in
> either case one has to be a pretty good guesser.

Yeah. If there are actually use-cases for knowing both things, then
we ought to record both. However, it's not real clear to me why
LSN would be interesting.

BTW, I spent a bit of time thinking about whether we should
record the timestamp at start or end of crash recovery; my conclusion
is we should record the latter. It would only make a difference to
people who wanted to inspect the value (a) while crash recovery is
in progress or (b) after a failed crash recovery. In both scenarios,
you have other mechanisms to discover the start time of the current
crash; while if we overwrite the pg_control field at the start,
there's no longer a way to know how long ago the previous crash was.
So it seems best not to overwrite the time of the previous crash
until we're up.

(If there is a reason to log LSN, maybe the argument is different
for that? Although I'd think that looking at the last checkpoint
REDO location is sufficient for figuring out where the current
crash recovery attempt started.)

regards, tom lane