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 1lq4mC-00054o-I3 for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Jun 2021 02:14:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lq4m9-00039L-KF for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Jun 2021 02:14:01 +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 1lq4m9-00039D-8R for pgsql-hackers@lists.postgresql.org; Mon, 07 Jun 2021 02:14:01 +0000 Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lq4m1-0003HB-FE for pgsql-hackers@postgresql.org; Mon, 07 Jun 2021 02:14:00 +0000 Received: by mail-io1-xd2c.google.com with SMTP id k22so16735774ioa.9 for ; Sun, 06 Jun 2021 19:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0SzbF9FrBpi/XfIKKpzqU0PvVUT1KRQrEWmBu+GpXfU=; b=Ch1zC7GfkR2BDRPpKf0zqk7r2mnhpQnxlUDOhb4ABh4fmC/tElqKIRf/YRKdBBZSrJ vx+DwVRsk1P4lZVlq/10rL9NGailAvh5qE2dCtFNIusRkvjfBXf1WYH48EmL23LNjC9c Ovfwd32eNQ1iHsot3l7tQz8GOn6s1ttNHyixifMPEPERdOtrIcnWykJAfXEHhS/WReJK losK6Be1l+trbaYTUqMq6HMWlMBxX9qP6/urW7zfQxaygxHFpzyQ4v4zBE3K6iWm3AkE +B5OA6W6aDqm1KS7TZh71M9uhj418PUgu2uj9+RNPCpZs4XUWopHPiGU0U3BtIFdqjxP yGqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0SzbF9FrBpi/XfIKKpzqU0PvVUT1KRQrEWmBu+GpXfU=; b=Vf+OvOaG7xcZ12ycvre7wUQkdMbh/UjPWifIdiqH4GrtLT4FqtS3Eex3YOfYMsbhQB ZOleSo/aiws50sRT/96mIJkrkz6FrSFuk/ZfL0Sl1gRfHEWitnMvL0vJyj7GaPYqbkLk /RWhfy4VQiRSjsUZ/Aer3/K5mrZdieMl+Uc8Z7aUnaFbbXEVNdWiM/3+gewH5hyKsV10 QYQtanej5JLqP8gKbjlAq7aQWhjQTyUdXatMRr3Dna2nslIii5fbWktbEA7Sb6LkYN/x fPan/7I9Eoc2PqoJGynHCbdG4pqlOdo57+rrRcGp4vHYUMU3IXhVh1UDyEKHkWvEIDOQ j/xw== X-Gm-Message-State: AOAM531Ro+JiCMfcigBX1FTijPewIQ8G5vOYHN0fdnSR9q8aTPyQpBPt IeggcNefz7f7V8QGrHQrdTCb2A== X-Google-Smtp-Source: ABdhPJzqWlF6CdIGhPeYVItgKmaDZyKDzy2Y0twJOP6XRkExbeRKuZw+Pes82OlYi7ZJRbgYOHrRjA== X-Received: by 2002:a05:6638:1391:: with SMTP id w17mr6157906jad.67.1623032030266; Sun, 06 Jun 2021 19:13:50 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id g9sm6640792ile.12.2021.06.06.19.13.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Jun 2021 19:13:49 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 9E081800C6F; Sun, 6 Jun 2021 21:13:48 -0500 (CDT) Date: Sun, 6 Jun 2021 21:13:48 -0500 From: Justin Pryzby To: Michael Paquier Cc: "Bossart, Nathan" , Fujii Masao , k.jamison@fujitsu.com, Thomas Munro , pgsql-hackers@postgresql.org, Nitin Jadhav Subject: Re: please update ps display for recovery checkpoint Message-ID: <20210607021348.GA14099@telsasoft.com> References: <549f04f1-6362-b599-c5e6-87330e36f03d@oss.nttdata.com> <20201211040210.GZ24052@telsasoft.com> <59A309AA-87C4-457E-A9D4-922BC5A418BA@amazon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="UHN/qo2QbUvPLonB" Content-Disposition: inline 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 --UHN/qo2QbUvPLonB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 14, 2020 at 12:01:33PM +0900, Michael Paquier wrote: > On Sat, Dec 12, 2020 at 12:41:25AM +0000, Bossart, Nathan wrote: > > On 12/11/20, 4:00 PM, "Michael Paquier" wrote: > >> My counter-proposal is like the attached, with the set/reset part not > >> reversed this time, and the code indented :p > > > > Haha. LGTM. > > Thanks. I have applied this one, then. To refresh: commit df9274adf adds "checkpoint" info to "ps", which previously continued to say "recovering NNNNN" even after finishing WAL replay, and throughout the checkpoint. Now, I wonder whether the startup process should also include some detail about "syncing data dir". It's possible to strace the process to see what it's doing, but most DBA would probably not know that, and it's helpful to know the status of recovery and what part of recovery is slow: sync, replay, or checkpoint. commit df9274adf improved the situation between replay and ckpoint, but it's still not clear what "postgres: startup" means before replay starts. There's some interaction between Thomas' commit 61752afb2 and recovery_init_sync_method - if we include a startup message, it should distinguish between "syncing data dirs (fsync)" and (syncfs). Putting this into fd.c seems to assume that we can clobber "ps", which is fine when called by StartupXLOG(), but it's a public interface, so I'm not sure if it's okay to assume that's the only caller. Maybe it should check if MyAuxProcType == B_STARTUP. -- Justin --UHN/qo2QbUvPLonB Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Show-syncing-data-directories-in-ps-display.patch" From a143c40fb2bad96d45f5cc3e22f70dd0e2d6b5c6 Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Sun, 6 Jun 2021 16:28:15 -0500 Subject: [PATCH] Show "syncing data directories" in ps display.. See also: df9274adf, which shows checkpoint output in ps, and 61752afb2 which adds syncfs. --- src/backend/storage/file/fd.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c index e8cd7ef088..692d7f16b7 100644 --- a/src/backend/storage/file/fd.c +++ b/src/backend/storage/file/fd.c @@ -99,6 +99,7 @@ #include "storage/fd.h" #include "storage/ipc.h" #include "utils/guc.h" +#include "utils/ps_status.h" #include "utils/resowner_private.h" /* Define PG_FLUSH_DATA_WORKS if we have an implementation for pg_flush_data */ @@ -3374,6 +3375,8 @@ SyncDataDirectory(void) * directories. */ + set_ps_display("syncing data directory (syncfs)"); + /* Sync the top level pgdata directory. */ do_syncfs("."); /* If any tablespaces are configured, sync each of those. */ @@ -3392,10 +3395,13 @@ SyncDataDirectory(void) /* If pg_wal is a symlink, process that too. */ if (xlog_is_symlink) do_syncfs("pg_wal"); + + set_ps_display(""); return; } #endif /* !HAVE_SYNCFS */ + set_ps_display("syncing data directory (fsync)"); /* * If possible, hint to the kernel that we're soon going to fsync the data * directory and its contents. Errors in this step are even less @@ -3421,6 +3427,8 @@ SyncDataDirectory(void) if (xlog_is_symlink) walkdir("pg_wal", datadir_fsync_fname, false, LOG); walkdir("pg_tblspc", datadir_fsync_fname, true, LOG); + + set_ps_display(""); } /* -- 2.17.0 --UHN/qo2QbUvPLonB--