Re: What's the best practice to compare the transaction with the checkpoint?

If we use V to compute another value, and then V is deleted and becomes a
dead tuple. Later, we do VACUUM, V and its file is removed. Then the system
crashes. When it tries to replay the xlog, it only sees the file path in
the checkpoint but the file doesn't exist any more.

What I am actually asking is that, is it possible that the replay depends
on a deleted value, which has been physically removed by a VACUUM.
Bear with my very basic knowledge in Postgres.

Best regards,
Jialun Zhang

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 于2020年7月6日周一 下午12:34写道：

> Jialun Zhang <reatank(at)gmail(dot)com> writes:
> > My question is that, consider such a situation (in the order of time):
> > 1. toast create a file for a value V;
> > 2. latest checkpoint;
> > 3. use V (here the file is read);
> > 4. delete the file when VACUUM deletes V;
> > 5. crash, then when we recover from the latest checkpoint, the file will
> be
> > accessed again but it has gone.
>
> What is "use V", and why would it be part of what is replayed in step 5?
> Replay generally doesn't do anything that could access potentially-deleted
> data, because depending on whether or not the updated page from step 4 got
> written out before crashing, there may or may not be any such tuple.
>
> The replay of step 4 would need to perform something like "delete the file
> for V if it exists, but don't complain if it does not", since we couldn't
> be sure which state we'll find on-disk.
>
> regards, tom lane
>