pgsql: BRIN: mask BRIN_EVACUATE_PAGE for WAL consistency checking

BRIN: mask BRIN_EVACUATE_PAGE for WAL consistency checking

That bit is unlogged and therefore it's wrong to consider it in WAL page
comparison.

Add a test that tickles the case, as branch testing technology allows.

This has been a problem ever since wal consistency checking was
introduced (commit a507b86900f6 for pg10), so backpatch to all supported
branches.

Author: 王海洋 (Haiyang Wang) <wanghaiyang(dot)001(at)bytedance(dot)com>
Reviewed-by: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Discussion: https://postgr.es/m/CACciXAD2UvLMOhc4jX9VvOKt7DtYLr3OYRBhvOZ-jRxtzc_7Jg@mail.gmail.com
Discussion: https://postgr.es/m/CACciXADOfErX9Bx0nzE_SkdfXr6Bbpo5R=v_B6MUTEYW4ya+cg@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/e44dae07f931383151e2eb34ed9b4cbf4bf14482

Modified Files
--------------
src/backend/access/brin/brin_pageops.c | 7 ++-
src/backend/access/brin/brin_xlog.c | 6 +++
src/test/modules/brin/Makefile | 2 +-
src/test/modules/brin/t/02_wal_consistency.pl | 75 +++++++++++++++++++++++++++
4 files changed, 88 insertions(+), 2 deletions(-)

On 2022-Aug-05, Alvaro Herrera wrote:

> Add a test that tickles the case, as branch testing technology allows.

One point here is that this confirms that the backpatched renaming alias
for PostgreSQL::Test::Cluster is working well.

Another is that, as far as I know, this is the going to be the only case
of any code being run under wal_consistency_checking=[not off]
regularly. 027_stream_regress.pl is equipped to do so, but as far as I
know we have no buildfarm animal with PG_EXTRA_TESTS set it so. I did
consider to make this new test conditional on having that flag be on,
but I disregarded it because of that.

A third point is that in branches 15+ I made it use pg_walinspect to
ensure that the desired WAL record is being emitted.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> BRIN: mask BRIN_EVACUATE_PAGE for WAL consistency checking

snapper doesn't like this too much, because

error running SQL: 'psql:<stdin>:17: ERROR: time zone "america/punta_arenas" not recognized
CONTEXT: PL/pgSQL function inline_code_block line 3 during statement block local variable initialization'

Is there a particular reason why you used that zone, rather than say UTC?

regards, tom lane

On Sat, Aug 6, 2022, at 9:01 PM, Tom Lane wrote:
> snapper doesn't like this too much, because
>
> error running SQL: 'psql:<stdin>:17: ERROR: time zone "america/punta_arenas" not recognized
> CONTEXT: PL/pgSQL function inline_code_block line 3 during statement block local variable initialization'
>
> Is there a particular reason why you used that zone, rather than say UTC?

None very good — I just wanted it to be not Moscow, which it was in the OP. I'll change it — to UTC, I suppose.

On 2022-Aug-06, Álvaro Herrera wrote:

> On Sat, Aug 6, 2022, at 9:01 PM, Tom Lane wrote:
> > snapper doesn't like this too much, because
> >
> > error running SQL: 'psql:<stdin>:17: ERROR: time zone "america/punta_arenas" not recognized
> > CONTEXT: PL/pgSQL function inline_code_block line 3 during statement block local variable initialization'
> >
> > Is there a particular reason why you used that zone, rather than say UTC?
>
> None very good — I just wanted it to be not Moscow, which it was in
> the OP. I'll change it — to UTC, I suppose.

Done.

--
Álvaro Herrera

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2022-Aug-06, Álvaro Herrera wrote:
>> None very good — I just wanted it to be not Moscow, which it was in
>> the OP. I'll change it — to UTC, I suppose.

> Done.

Thanks. I wondered why this was a problem, when we have various
other dependencies on specific zone names in the tests. The
answer seems to be that America/Punta_Arenas is a fairly new
zone name: it was introduced in tzdata 2017a [1]. So snapper's
tzdata must be older than that. I see it is using the system
tzdata not our own:

'--with-system-tzdata=/usr/share/zoneinfo',

You would've been fine with America/Santiago, likely :-(

regards, tom lane

[1] http://mm.icann.org/pipermail/tz-announce/2017-February/000045.html