Re: Lack of PageSetLSN in heap_xlog_visible

On Thu, 2022-10-13 at 12:50 +0300, Konstantin Knizhnik wrote:
>          /*
>           * We don't bump the LSN of the heap page when setting the
> visibility
>           * map bit (unless checksums or wal_hint_bits is enabled, in
> which
>           * case we must), because that would generate an unworkable
> volume of
>           * full-page writes.

It clearly says there that it must set the page LSN, but I don't see
where that's happening. It seems to go all the way back to the original
checksums commit, 96ef3b8ff1.

I can reproduce a case where a replica ends up with a different page
header than the primary (checksums enabled):

Primary:
create extension pageinspect;
create table t(i int) with (autovacuum_enabled=off);
insert into t values(0);

Shut down and restart primary and replica.

Primary:
insert into t values(1);
vacuum t;

Crash replica and let it recover.

Shut down and restart primary and replica.

Primary:
select * from page_header(get_raw_page('t', 0));

Replica:
select * from page_header(get_raw_page('t', 0));

The LSN on the replica is lower, but the flags are the same
(PD_ALL_VISIBLE set). That's a problem, right? The checksums are valid
on both, though.

It may violate our torn page protections for checksums, as well, but I
couldn't construct a scenario for that because recovery can only create
restartpoints at certain times.

> But it still not clear for me that not bumping LSN in this place is
> correct if wal_log_hints is set.
> In this case we will have VM page with larger LSN than heap page,
> because visibilitymap_set
> bumps LSN of VM page. It means that in theory after recovery we may
> have
> page marked as all-visible in VM,
> but not having PD_ALL_VISIBLE  in page header. And it violates VM
> constraint:

I'm not quite following this scenario. If the heap page has a lower LSN
than the VM page, how could we recover to a point where the VM bit is
set but the heap flag isn't? And what does it have to do with
wal_log_hints/checksums?

--
Jeff Davis
PostgreSQL Contributor Team - AWS