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 1ov2BJ-00038b-FT for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Nov 2022 20:05:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ov2BI-0003Cn-2c for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Nov 2022 20:05:16 +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 1ov2BH-0003Ce-Mz for pgsql-hackers@lists.postgresql.org; Tue, 15 Nov 2022 20:05:15 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ov2BE-0004lP-R6 for pgsql-hackers@lists.postgresql.org; Tue, 15 Nov 2022 20:05:15 +0000 Received: by mail-lj1-x235.google.com with SMTP id s24so19025569ljs.11 for ; Tue, 15 Nov 2022 12:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aYNl26u9rJkc0UYEo50EBtX2Ra2eYktG1Fluu2Yt5+g=; b=ofCciw8YNrJoNLSn10LhNaSD9nMvS6POlttAFLSvm5+KbXGw3cq+bWH3eFJunrcrFy KIMcMy2P4GJrg7sOiG5tsmYFIBzgNdt9vhh9Ip+3Sz1GW9KuMuMF+sRIdyR5Lql+574e Ah/GicrT3j9Q64bLrZq+/uo4nfj9AflpYhcqK2aDkzPBqaIoDW+kc2rxEmm+mjDEjfwi Z/rvEVWHEnezug8kEP/sd1UVNMoA1vqdJeJoc66mFmlFelOWb5r8ouz2548oaWPL4DP2 g0g189nU7hZEePHMnRCclI4gFTl1ipV8Jm1LfSflae+HOFnFCvJZQkKySt9MguuQNk76 JaLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aYNl26u9rJkc0UYEo50EBtX2Ra2eYktG1Fluu2Yt5+g=; b=JZSuxrj+vcgKGqjofXXXRMaqfTreyI+mFnEgZd486jWOAYFSHLqQdrUCHObUt7dE/L hYnnaH/1vwb7wXjiVC3xZArNX0e79ZN32RKkaLbTzz2aUpf5P4xxt1GXlOk+Am+1HFM7 Gr8/Xbj2nZ+5lc2qtDlfEqBW1CP7ReVPucweKgTt1JwQZa1cYMSQPdvIypAgYM6JvZz4 KkMJE8WTILqh/61wXHx36vuQDiA565MtOOd9afsXIWb2C1creaTFsveDZZtkXdScmVfQ ObpymlselWUTi47czvH+w0zew9oKbRKvfNLlsvBbnfq5kP33WbRqewPqzKJOCZrFJKox oPUQ== X-Gm-Message-State: ANoB5pkyEbsc7dkDuFWAxDrtYmXLFj8R3E138+R36lfo53cw1gUWM0cI Lj/0ZXvB2mxmgk5/PLulwaswIxsCdH6Miv4e2vE= X-Google-Smtp-Source: AA0mqf4hzwliyMN0wGkksUQauCUNLveAzH9OgBAFZvNvNE5onx1aqmTr4XgGzzPqevDKRoNDx00FhK65qBwaCWaYX54= X-Received: by 2002:a2e:5c7:0:b0:279:fbb:5f6e with SMTP id 190-20020a2e05c7000000b002790fbb5f6emr2283511ljf.132.1668542710622; Tue, 15 Nov 2022 12:05:10 -0800 (PST) MIME-Version: 1.0 References: <20220319001556.atuqbmafvc73pa2k@alap3.anarazel.de> <20220707000446.hefgyu5xikxwt4md@alap3.anarazel.de> In-Reply-To: From: Robert Haas Date: Tue, 15 Nov 2022 15:04:59 -0500 Message-ID: Subject: Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) To: "Drouvot, Bertrand" Cc: Nitin Jadhav , Andres Freund , Bharath Rupireddy , Matthias van de Meent , Ashutosh Sharma , Julien Rouhaud , Bruce Momjian , Tom Lane , Magnus Hagander , PostgreSQL Hackers 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, Nov 4, 2022 at 4:27 AM Drouvot, Bertrand wrote: > Please find attached a rebase in v7. I don't think it's a good thing that this patch is using the progress-reporting machinery. The point of that machinery is that we want any backend to be able to report progress for any command it happens to be running, and we don't know which command that will be at any given point in time, or how many backends will be running any given command at once. So we need some generic set of counters that can be repurposed for whatever any particular backend happens to be doing right at the moment. But none of that applies to the checkpointer. Any information about the checkpointer that we want to expose can just be advertised in a dedicated chunk of shared memory, perhaps even by simply adding it to CheckpointerShmemStruct. Then you can give the fields whatever names, types, and sizes you like, and you don't have to do all of this stuff with mapping down to integers and back. The only real disadvantage that I can see is then you have to think a bit harder about what the concurrency model is here, and maybe you end up reimplementing something similar to what the progress-reporting stuff does for you, and *maybe* that is a sufficient reason to do it this way. But I'm doubtful. This feels like a square-peg-round-hole situation. -- Robert Haas EDB: http://www.enterprisedb.com