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 1mscpd-0004On-0l for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Dec 2021 03:32:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mscpb-0007Qf-ST for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Dec 2021 03:32:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mscp6-0004FG-8R for pgsql-hackers@lists.postgresql.org; Thu, 02 Dec 2021 03:31:52 +0000 Received: from mail-io1-xd33.google.com ([2607:f8b0:4864:20::d33]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mscp3-0005fL-0J for pgsql-hackers@postgresql.org; Thu, 02 Dec 2021 03:31:51 +0000 Received: by mail-io1-xd33.google.com with SMTP id x6so33420076iol.13 for ; Wed, 01 Dec 2021 19:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=kOQM6fLhcZfBtr6LsVI7PfEJ7BYyj+TmZbgGq3TaoXE=; b=dp2KDDYLRl2O7Flok+6LZO00853JfLR1C2GCzSFDZwwlQyaQWXj7kZ/fa+c7SgVkOF TT7UCMVr9huMe8Pso/yNmYepkHDZkNZata2zj/pJlgAseS32B/++7wdzBv+ryfBhVoDT 6bfP/PqkbGzRlJVwPG4+QrB+QgOPNhTjr+BMewArK+6q7RqX9+lfvY11nxFcPauXlU3N 5qsRtBOX5IlIFA/oTODk6YHhXn0yzAhDT9UTHdhWtRyVP2om0C+Axd1apKlScs5higkg YTzVVur2vMgQm7n3iZn3Bdr8pWtnOgUTZhdeNP8jeROMpZD7hRAqILPHOF3NlsnV4UZz IbcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=kOQM6fLhcZfBtr6LsVI7PfEJ7BYyj+TmZbgGq3TaoXE=; b=2q1zzcbINTNG+4FGYJiS8Tb/idKeP2FZIfoSGZJuOlYdYYsYYFxHT0EPrqSqS4z+Li vqLafV8FjK1aQHyHMPlheOTy7Db0lZKMtDcgxEr9cmqRNffjyYujFF62AwCqm/VFTxox yFC0cB72Ak0EQMgvB2PnKnOFJlmjD7lL1c6msnhTIr4E+hrLRAyVkY7mUr7MuwiuJ4f5 UFP8cppEwslw1QmbAKlzPxL6Gs7gg8iyVqIVA9ekhl/VbGSs2gU2jLPy0J/v7IDHSDym 0ODsS7SHl2WpuWUP8lBvJtnmrw9jEEn9SxYBtH1ZTyYA3gENq2GLQs2JG2N7SrkbdwA+ y+QA== X-Gm-Message-State: AOAM533YvRlwtPp+jKjAlY3GDsVgK2mqNRihxoYD2SznzcdHcbyAyXqH Sb5wbKPh+gI/2fKc06msol6urg== X-Google-Smtp-Source: ABdhPJxUnGVITi+fOPjfE8xSjcL68RxK1PEDAJqXUiBXlDYzAY3IHQpCd+W+CSDDncv7uBohsk/QdQ== X-Received: by 2002:a6b:5c02:: with SMTP id z2mr13420005ioh.138.1638415907171; Wed, 01 Dec 2021 19:31:47 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id l3sm1244289ilv.37.2021.12.01.19.31.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Dec 2021 19:31:46 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id AB437800C52; Wed, 1 Dec 2021 21:31:45 -0600 (CST) Date: Wed, 1 Dec 2021 21:31:45 -0600 From: Justin Pryzby To: Melanie Plageman Cc: Andres Freund , Alvaro Herrera , Kyotaro Horiguchi , Magnus Hagander , pgsql-hackers@postgresql.org, Lukas Fittl , Thomas Munro Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) Message-ID: <20211202033145.GK17618@telsasoft.com> References: <202109302315.65qtfrmgbpzt@alvherre.pgsql> <20211008175620.nspjy6wwmzvyzkrg@alap3.anarazel.de> <20211019192931.eeeohw6yrvqe6bol@alap3.anarazel.de> <20211119164952.mlw7ecj4xxliuuut@alap3.anarazel.de> <20211125011559.GC17618@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Dec 01, 2021 at 04:59:44PM -0500, Melanie Plageman wrote: > Thanks for the review! > > On Wed, Nov 24, 2021 at 8:16 PM Justin Pryzby wrote: > > You wrote beentry++ at the start of two loops, but I think that's wrong; it > > should be at the end, as in the rest of the file (or as a loop increment). > > BackendStatusArray[0] is actually used (even though its backend has > > backendId==1, not 0). "MyBEEntry = &BackendStatusArray[MyBackendId - 1];" > > I've fixed this in v16 which I will attach to the next email in the thread. > > > You could put *_NUM_TYPES as the last value in these enums, like > > NUM_AUXPROCTYPES, NUM_PMSIGNALS, and NUM_PROCSIGNALS: > > > > +#define IOOP_NUM_TYPES (IOOP_WRITE + 1) > > +#define IOPATH_NUM_TYPES (IOPATH_STRATEGY + 1) > > +#define BACKEND_NUM_TYPES (B_LOGGER + 1) > > I originally had it as you describe, but based on this feedback upthread > from Álvaro Herrera: I saw that after I made my suggestion. Sorry for the noise. Both ways already exist in postgres and seem to be acceptable. > > There's extraneous blank lines in these functions: > > +pgstat_recv_resetsharedcounter > I didn't see one here => The extra blank line is after the RESET_BUFFERS memset. > + * Reset the global, bgwriter and checkpointer statistics for the > + * cluster. The first comma in this comment was introduced in 1bc8e7b09, and seems to be extraneous, since bgwriter and checkpointer are both global. With the comma, it looks like it should be memsetting 3 things. > + /* Don't count dead backends. They should already be counted */ Maybe this comment should say ".. they'll be added below" > + row[COLUMN_BACKEND_TYPE] = backend_type_desc; > + row[COLUMN_IO_PATH] = CStringGetTextDatum(GetIOPathDesc(io_path)); > + row[COLUMN_ALLOCS] += io_ops->allocs - resets->allocs; > + row[COLUMN_EXTENDS] += io_ops->extends - resets->extends; > + row[COLUMN_FSYNCS] += io_ops->fsyncs - resets->fsyncs; > + row[COLUMN_WRITES] += io_ops->writes - resets->writes; > + row[COLUMN_RESET_TIME] = reset_time; It'd be clearer if RESET_TIME were set adjacent to BACKEND_TYPE and IO_PATH. > > Rather than memset(), you could initialize msg like this. > > PgStat_MsgIOPathOps msg = {0}; > > though changing the initialization to universal zero initialization > seems to be the correct way, I do get this compiler warning when I make > the change > > pgstat.c:3212:29: warning: suggest braces around initialization of subobject [-Wmissing-braces] > > I have seem some comments online that say that this is a spurious > warning present with some versions of both gcc and clang when using > -Wmissing-braces to compile code with universal zero initialization, but > I'm not sure what I should do. I think gcc is suggesting to write something like {{0}}, and I think the online commentary you found is saying that the warning is a false positive. So I think you should ignore my suggestion - it's not worth the bother. This message needs to be updated: errhint("Target must be \"archiver\", \"bgwriter\", or \"wal\"."))) When I query the view, I see reset times as: 1999-12-31 18:00:00-06. I guess it should be initialized like this one: globalStats.bgwriter.stat_reset_timestamp = ts The cfbot shows failures now (I thought it was passing with the previous patch, but I suppose I'm wrong.) It looks like running recovery during single user mode hits this assertion. TRAP: FailedAssertion("beentry", File: "../../../../src/include/utils/backend_status.h", Line: 359, PID: 3499) -- Justin