Обсуждение: 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.001@bytedance.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.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(-)
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, becauseerror running SQL: 'psql:<stdin>:17: ERROR: time zone "america/punta_arenas" not recognizedCONTEXT: 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]. 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