pgsql: BRIN: mask BRIN_EVACUATE_PAGE for WAL consistency checking

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@alvh.no-ip.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@alvh.no-ip.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]http://mm.icann.org/pipermail/tz-announce/2017-February/000045.html. 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