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 1m7iN6-00061M-9Z for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Jul 2021 17:57: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 1m7iN4-0003IJ-1W for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Jul 2021 17:57:02 +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 1m7iN3-0003Fd-Do for pgsql-hackers@lists.postgresql.org; Sun, 25 Jul 2021 17:57:01 +0000 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m7iMz-0000J7-7O for pgsql-hackers@postgresql.org; Sun, 25 Jul 2021 17:56:59 +0000 Received: by mail-io1-xd2a.google.com with SMTP id a13so9022518iol.5 for ; Sun, 25 Jul 2021 10:56:57 -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=yxhXfsc2oRsjjLJPXOgiIeV6ZGZgtCuPHbJPe/QhiR8=; b=rdVPBugBEwglIARmK8NkRS/kCDwg9yhmo2D/gGzaCHckgCSQqcy9sYa4kZN2+mCfhc 9Ygq65N6WWpEUDcSIcF/21EJ2ukVi2rtBF1BRaioPMuYs0kGI+8BEaRld0nnTM3zXVuT QSEyKKfKgIlD57wlsZaQ+pccDYi0uhL1oN/bT1R11kRCLV5KPCp4LTf6/Bcnon54308d NLE6YoPKFXpfRLipeSMf9qC7X77UJQcoNyZ7kCQQdEyRTkc8zcFyzTg8/qJT5+zqRadE hJ6Y0Awj2QbvOF+77jQPa6kuLbXKhbhzE/U+NSP2NJr1zLc/rwCVFkd1PIQBG7r2j2G4 aiQg== 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=yxhXfsc2oRsjjLJPXOgiIeV6ZGZgtCuPHbJPe/QhiR8=; b=KCIqft0voHv27eusMNzfKjZagkfA/B9HFOCnwA/CG2Gp9Mw8IbHKhaOlBmfs4bRJCf 9Ge8kuxdItEaBNu5Db7JGTQam2/rSAl/8lGfS7yxhcK3cUvtAtI11+DTQg9oQWH9D1Ov s7RyUzYxiRZt2e9bvXtkkXMsrrJKPL4bqr86fjkUO2GxtnqBm7OH6+RnRxCHRjEv3mys vFsarcKBcjEp6bxK9ctXEFfU7qAveQYcbJO+m+AsaQTYH8L0wfGHixTmKOEPyicawpCR VcktelBv0IV48evLGs67zbR1F8R7S9P9Aat74tXBtc4GOvSTtc14J3jlrcug909dfdD5 wc/g== X-Gm-Message-State: AOAM530qRmfk6RaMD/LtR3pJPqBDtj+G16HXrVuWFmmmN6jgdrA9BqUp Yp2Io0IEmlzcTqoEpsXkF9g0NA== X-Google-Smtp-Source: ABdhPJxIeFNb+EnYnb6beRqgxcxLPkig1ur/ThamXgrHUQl/8wn0xd4ZoencR8O1KL5UbXqwHxC5Mw== X-Received: by 2002:a5e:9e02:: with SMTP id i2mr11907064ioq.198.1627235816386; Sun, 25 Jul 2021 10:56:56 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id c1sm12433041ili.35.2021.07.25.10.56.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jul 2021 10:56:55 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id A362F800AEA; Sun, 25 Jul 2021 12:56:54 -0500 (CDT) Date: Sun, 25 Jul 2021 12:56:54 -0500 From: Justin Pryzby To: Nitin Jadhav Cc: Bharath Rupireddy , Tom Lane , Robert Haas , Andres Freund , Stephen Frost , Magnus Hagander , Thomas Munro , Pg Hackers Subject: Re: when the startup process doesn't (logging startup delays) Message-ID: <20210725175654.GA23997@telsasoft.com> References: <20210609161918.GY16435@telsasoft.com> <20210610100125.GE16435@telsasoft.com> <20210617125254.GB31772@telsasoft.com> <20210721131326.GA19620@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 On Fri, Jul 23, 2021 at 04:09:47PM +0530, Nitin Jadhav wrote: > > I think walkdir() should only call LogStartupProgress(FSYNC_IN_PROGRESS, path); > > when action == datadir_fsync_fname. > > I agree and fixed it. I saw that you fixed it by calling InitStartupProgress() after the walkdir() calls which do pre_sync_fname. So then walkdir is calling LogStartupProgress(STARTUP_PROCESS_OP_FSYNC) even when it's not doing fsync, and then LogStartupProgress() is returning because !AmStartupProcess(). That seems indirect, fragile, and confusing. I suggest that walkdir() should take an argument for which operation to pass to LogStartupProgress(). You can pass a special enum for cases where nothing should be logged, like STARTUP_PROCESS_OP_NONE. On Wed, Jul 21, 2021 at 04:47:32PM +0530, Bharath Rupireddy wrote: > 1) I still don't see the need for two functions LogStartupProgress and > LogStartupProgressComplete. Most of the code is duplicate. I think we > can just do it with a single function something like [1]: I agree that one function can do this more succinctly. I think it's best to use a separate enum value for START operations and END operations. switch(operation) { case STARTUP_PROCESS_OP_SYNCFS_START: ereport(...); break; case STARTUP_PROCESS_OP_SYNCFS_END: ereport(...); break; case STARTUP_PROCESS_OP_FSYNC_START: ereport(...); break; case STARTUP_PROCESS_OP_FSYNC_END: ereport(...); break; ... -- Justin