Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qV1Zz-00G73T-6G for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Aug 2023 03:15:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qV1Zx-005KR2-ED for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Aug 2023 03:15:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qV1Zw-005KQu-Uj for pgsql-hackers@lists.postgresql.org; Sun, 13 Aug 2023 03:15:45 +0000 Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qV1Zo-002C3w-TU for pgsql-hackers@postgresql.org; Sun, 13 Aug 2023 03:15:43 +0000 Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-d62b9bd5b03so3104630276.1 for ; Sat, 12 Aug 2023 20:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1691896534; x=1692501334; h=user-agent:content-disposition:mime-version:message-id:subject:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=OCw3qe4UyXe8J1ibv0gqLKQXTF1frMTPJgsopbNzAB8=; b=TTHU0GC9+ne9ZrZ1YSWtUIuZt1hSbk48B07HMlRFckxl0c5HNNz/FxKVQYPzQqpn+r oMTzcpf5CRaRW/BoAE8uOe5ybalrpP3Ct2OBSBdYkM/L1FJHueR+/GtyhpXVj0PQwbZj s8uwah0uOHz+j0pt5XpEShsq6DtMn4X/hGwUI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691896534; x=1692501334; h=user-agent:content-disposition:mime-version:message-id:subject:to :from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OCw3qe4UyXe8J1ibv0gqLKQXTF1frMTPJgsopbNzAB8=; b=MMSn7W9lij9MAGs3zqZB72ztvoW4nx14QGJ6itOS0PGl0Iy+tCU+718gjmqPt78/b3 CPeN9ysxqDprOnjeckudcMBgPFsDQms/ONtBAgKVwdxrEmzQswZ0UphY0GKhU6AfJoWU zEybC6OrzUjpKCpEKM7OwnYNVVa2yXfxkCy0k+Qb2PZt7PUE3GdfRHv+tXa4E/DaPoeT 5lGhDuihtgNDQyFkwOFIjSYQ3/fUySUFJ/cd6MDEcTlsWM4gzSvhvq+tHiN0hgYdj12R OTJPn32YJss1CufUP2PlF6syZzXRyJ9+0nczKOLI+Lgxz0FIhiG1bqoeYL5mogakxwuB M69w== X-Gm-Message-State: AOJu0YyrSebvX+rn6hprZ26nLQIYGfJBtSLR7ZOrAGyiBtx8AyTogZhY nlxC3E81oGt4/pFtkCuRrOuV3PjSylrLvvlOEJ8= X-Google-Smtp-Source: AGHT+IFhpK4TdJQER4WPS/sy2wflf66hYGBCUH9DS+4hafMEleEojwDQscFi4dubrygTcr671cjZoQ== X-Received: by 2002:a25:d304:0:b0:d09:377a:7bf7 with SMTP id e4-20020a25d304000000b00d09377a7bf7mr6856725ybf.16.1691896533996; Sat, 12 Aug 2023 20:15:33 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id e188-20020a25e7c5000000b00d636d05d3e6sm1756116ybh.19.2023.08.12.20.15.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2023 20:15:33 -0700 (PDT) Date: Sat, 12 Aug 2023 20:15:31 -0700 From: Noah Misch To: pgsql-hackers@postgresql.org Subject: pg_waldump vs. all-zeros WAL files; server creation of such files Message-ID: <20230813031531.GC2326466@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The attached 010_zero.pl, when run as part of the pg_waldump test suite, fails at today's master (c36b636) and v15 (1bc19df). It passes at v14 (5a32af3). Command "pg_waldump --start 0/01000000 --end 0/01000100" fails as follows: pg_waldump: error: WAL segment size must be a power of two between 1 MB and 1 GB, but the WAL file "000000010000000000000002" header specifies 0 bytes Where it fails, the server has created an all-zeros WAL file under that name. Where it succeeds, that file doesn't exist at all. Two decisions to make: - Should a clean server shutdown ever leave an all-zeros WAL file? I think yes, it's okay to let that happen. - Should "pg_waldump --start $X --end $Y" open files not needed for the requested range? I think no. Bisect of master got: 30a53b7 Wed Mar 8 16:56:37 2023 +0100 Allow tailoring of ICU locales with custom rules Doesn't fail at $(git merge-base REL_15_STABLE master). Bisect of v15 got: 811203d Sat Aug 6 11:50:23 2022 -0400 Fix data-corruption hazard in WAL-logged CREATE DATABASE. I suspect those are innocent. They changed the exact WAL content, which I expect somehow caused creation of segment 2. Oddly, I find only one other report of this: https://www.postgresql.org/message-id/CAJ6DU3HiJ5FHbqPua19jAD%3DwLgiXBTjuHfbmv1jCOaNOpB3cCQ%40mail.gmail.com Thanks, nm --d6Gm4EdcadzBjdND Content-Type: application/x-perl Content-Disposition: attachment; filename="010_zero.pl" Content-Transfer-Encoding: quoted-printable =0A# Copyright (c) 2021-2023, PostgreSQL Global Development Group=0A=0Ause = strict;=0Ause warnings;=0Ause PostgreSQL::Test::Cluster;=0Ause PostgreSQL::= Test::Utils;=0Ause Test::More;=0A=0Amy $node =3D PostgreSQL::Test::Cluster-= >new('main');=0A$node->init;=0A=0Asub my_waldump()=0A{=0A system('ls', $nod= e->data_dir . "/pg_wal");=0A command_ok([ 'pg_waldump', '-p', $node->data_d= ir,=0A qw(--start 0/01000000 --end 0/01000100) ],=0A 'runs');=0A}= =0A=0A$node->start;=0A$node->command_ok([qw(createdb test)]);=0Amy_waldump;= =0A$node->stop;=0Amy_waldump;=0A$node->start;=0Amy_waldump;=0A=0Adone_testi= ng;=0A --d6Gm4EdcadzBjdND--