Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nNajJ-0003Aa-B8 for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Feb 2022 13:33:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nNajI-0005L2-8L for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Feb 2022 13:33:52 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nNajH-0005Kl-VU for pgsql-hackers@lists.postgresql.org; Fri, 25 Feb 2022 13:33:51 +0000 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nNajF-0002uk-PL for pgsql-hackers@postgresql.org; Fri, 25 Feb 2022 13:33:50 +0000 Received: by mail-pf1-x434.google.com with SMTP id g1so4703577pfv.1 for ; Fri, 25 Feb 2022 05:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SVSx8Na86GiW9kje3aBknXcvxUoP+IGuqm8X7aTNVCQ=; b=BbAjHqD4K79ScPQNRMAt7dNLhVHV9s/DAnNeG/kDZBPYlJ89GWBzIEkrV5OuxBKMys qWrK3hfgzjDM/1Tcl1aaZr89gsZYVxevbQvqW4qTyxQCD7wiGKMPv2uvmIyMiv+blz1U eftyu13WjOsE5DY0SvzzIYZfx1Wo0aH6YiWt3sxGFj2tvQrO6jYVUdfg0fgDd3TeULnj B1nL1xuG8JTNLcx+MTIrqaZyonBfqamp1Ns7eMR/dukdBjdoG2T32oglFxxQ/rn+zyRo 0VSGLyoQTR3CdvdYV8PQafj0Sf6zUrDFLT9JE9pJ73Vn9qpCwf2E23tLNluTBvrnrs6O SKNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SVSx8Na86GiW9kje3aBknXcvxUoP+IGuqm8X7aTNVCQ=; b=74jXfzBljqo65yysIh3aG0BhJisUE68KfXBrMYIdi/K/8cnh0LknT1Hm5PkCJE3oFj YVd3mDHQDIOMx7cPUbCkIgxI2bod8eh3atPF95IlZ7NZOS3/lIPFcm6R37fkab+s66Vk 6dNy0qPtpU1LUmoN92BPfXc7Ejm9AajVXaK9IV/dZhYgmjnpRMVNWnqlLUYPYyFCRXLm /7A9ZG+JdGv1mhuhHCdRlRTz7UfZVNXD/KGqk8Dko7GZp7a9nySLIv+c5gBhph++JVf7 S7+p5b/iLuoeKlyMaQFlvBgMpbUDML/8xzR3aZ7UaLIUiPWfNRN2e4ZLtDPbS508rZOU WArw== X-Gm-Message-State: AOAM533XmJEBaJRGSmj9ygRFGjU4w7S34anD+e5xA7gBYQjPSU8YOK3c vqucd2QdO9gl5G/ccrrP4coSwRS/tiWLdNGk+incztZmMw4= X-Google-Smtp-Source: ABdhPJwQGldnqbu1RsffQbOdrdcmmC591EP9IKZLgxTXEmSwRC9PJoLm7+jIbMxBjmQR09FfRxck8pwImjhqWnz4xYc= X-Received: by 2002:aa7:9429:0:b0:4e1:5814:79b3 with SMTP id y9-20020aa79429000000b004e1581479b3mr7721493pfo.82.1645796028702; Fri, 25 Feb 2022 05:33:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bharath Rupireddy Date: Fri, 25 Feb 2022 19:03:38 +0530 Message-ID: Subject: Re: [PATCH] add relation and block-level filtering to pg_waldump To: David Christensen Cc: PostgreSQL-development Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Feb 25, 2022 at 12:36 AM David Christensen wrote: > > Greetings, > > This patch adds the ability to specify a RelFileNode and optional BlockNum to limit output of > pg_waldump records to only those which match the given criteria. This should be more performant > than `pg_waldump | grep` as well as more reliable given specific variations in output style > depending on how the blocks are specified. > > This currently affects only the main fork, but we could presumably add the option to filter by fork > as well, if that is considered useful. Thanks for the patch. This is not adding something that users can't do right now, but definitely improves the usability of the pg_waldump as it avoids external filterings. Also, it can give the stats/info at table and block level. So, +1 from my side. I have some comments on the patch: 1) Let's use capitalized "OID" as is the case elsewhere in the documentation. + specified via tablespace oid, database oid, and relfilenode separated 2) Good idea to specify an example: + by slashes. Something like, "by slashes, for instance, XXXX/XXXX/XXXX 3) Crossing 80 char limit +/* + * Boolean to return whether the given WAL record matches a specific relation and optional block + */ +static bool +XLogRecordMatchesRelationBlock(XLogReaderState *record, RelFileNode matchRnode, BlockNumber matchBlock ) + pg_log_error("could not parse block number \"%s\"", optarg); + pg_log_error("could not parse relation from \"%s\" (expecting \"spc/dat/rel\")", optarg); 4) How about (expecting \"tablespace OID/database OID/relation OID\")? Let's be clear. + pg_log_error("could not parse relation from \"%s\" (expecting \"spc/dat/rel\")", optarg); 5) I would also see a need for "filter by FPW" i.e. list all WAL records with "FPW". 6) How about "--block option requires --relation option" or some other better phrasing? + pg_log_error("cannot filter by --block without also filtering --relation"); 7) Extra new line between } and return false; + return true; + } + return false; +} 8) Can we have this for-loop local variables instead of function level variables? + RelFileNode rnode; + ForkNumber forknum; + BlockNumber blk; Regards, Bharath Rupireddy.