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 1lq1At-0003q8-Ep for pgsql-hackers@arkaria.postgresql.org; Sun, 06 Jun 2021 22:23:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lq1Aq-0005kR-Ba for pgsql-hackers@arkaria.postgresql.org; Sun, 06 Jun 2021 22:23:16 +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 1lq1Ap-0005kJ-VH for pgsql-hackers@lists.postgresql.org; Sun, 06 Jun 2021 22:23:16 +0000 Received: from mail-il1-x134.google.com ([2607:f8b0:4864:20::134]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lq1Ai-0007a4-8a for pgsql-hackers@postgresql.org; Sun, 06 Jun 2021 22:23:14 +0000 Received: by mail-il1-x134.google.com with SMTP id b5so14347912ilc.12 for ; Sun, 06 Jun 2021 15:23:08 -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=3cUhE1MNg6sPPh108p89YzTHgTY3Ppj+GuqMa9+Qolk=; b=z8EzCowiCK7pHOoREZqbquXE7DwHWbGfnvuAHLYqiEgTmydC9gHilju4pLoRQnPLiU tV7/Xyp5Ojd9T6hA7+gTJPFqBFsuNrvwG6AxPdc1aq96GGKj93QYI6c4wal6Vplhf5IM nKsRE1VHa6etx6adkbFTdVMKFtIhFmTMuM+d1JqDEnRpl4rE9gos7EimZbNnzI7RoMjH ynauTN15a2gKrHGUClJgAjqN+8qWQCSQ+afJG9+McMkt3yjZUJr2DBHZariDD0GfpXlg PkAnvunY5FmJwsRE8KgAOz9O1dzk9RDWb7Y5C930vdNmIqPWh6+/OefWNawWmChx1x3u k1ZQ== 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=3cUhE1MNg6sPPh108p89YzTHgTY3Ppj+GuqMa9+Qolk=; b=OmaXCRdzhFAZU1sq6X5XbkHgOvFqaC8Igs71OUgyJx22g1zlvthZf5wkbUgw7ZTSZe k076PRRIPLnH65lr7EFX3SQFITcqHgYLG+6qewcS6h58NYgR7L//Pp8f17UsF7ek/nql gtHjV1RnWOZSjyl2Eptl4Zunx7omCH/s0XH4vjboSFyuq5ieeNh052LuiaZjwyNchNmm CuOiFrRM59StVBtTfY1h1ZUJM+6JdNAkcrvL9efFubuB8MXd8z4U21UrbFlj8ca3ilDg CrcaK0vqt5xc0HwxfiJ/W9JWnM+pSD13Euqk6E8cWlKkedHuilAjTsBQnbiqLqtx4dBi TJSA== X-Gm-Message-State: AOAM531TIiGZKUuXtvyEKKlkcJv0YXN/YMJmbdGFwXoGzXX04RV9N4QJ wsSCLNWOANX19CPV8eh5Fq3gVQ== X-Google-Smtp-Source: ABdhPJyiRpFCv/cMyx6yj2jXYnCtcgeeAPVS0D5U2Eyfx+SwZi0GOEsb7rP3GgIF5pUDUs91PveoAA== X-Received: by 2002:a92:2c0a:: with SMTP id t10mr13227389ile.25.1623018187170; Sun, 06 Jun 2021 15:23:07 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id r6sm972742ilg.46.2021.06.06.15.23.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Jun 2021 15:23:06 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id E35DC800C6F; Sun, 6 Jun 2021 17:23:05 -0500 (CDT) Date: Sun, 6 Jun 2021 17:23:05 -0500 From: Justin Pryzby To: Nitin Jadhav Cc: Robert Haas , Andres Freund , Stephen Frost , Tom Lane , Magnus Hagander , Thomas Munro , pgsql-hackers@postgresql.org Subject: Re: when the startup process doesn't Message-ID: <20210606222305.GZ14099@telsasoft.com> References: <20210420171720.56599607@firost> <631849.1618942988@sss.pgh.pa.us> <20210420185150.GL20766@tamriel.snowman.net> <633337.1618945018@sss.pgh.pa.us> <20210420203642.nvxvolm37f2k6prj@alap3.anarazel.de> <20210421183624.GP20766@tamriel.snowman.net> <20210421193605.cubavrq7q5bqkf4i@alap3.anarazel.de> <20210422010919.4b655015@firost> 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, Jun 04, 2021 at 07:49:21PM +0530, Nitin Jadhav wrote: > I have added the proper logs in all of the above scenarios. > > Following is the sample log displayed during server startup when the > time period is set to 10ms. > > 2021-06-04 19:40:06.390 IST [51116] LOG: Syncing data directory, elapsed time: 14.165 ms, current path: ./base/13892/16384_fsm > 2021-06-04 19:40:06.399 IST [51116] LOG: Syncing data directory completed after 22.661 ms |2021-06-04 19:40:07.222 IST [51116] LOG: Performing crash recovery, elapsed time: 820.805 ms, current LSN: 0/76F6F10 |2021-06-04 19:40:07.227 IST [51116] LOG: invalid record length at 0/774E758: wanted 24, got 0 |2021-06-04 19:40:07.227 IST [51116] LOG: redo done at 0/774E730 system usage: CPU: user: 0.77 s, system: 0.03 s, elapsed: 0.82 s Should it show the rusage ? It's shown at startup completion since 10a5b35a0, so it seems strange not to show it here. + log_startup_process_progress("Syncing data directory", path, false); I think the fsync vs syncfs paths should be distinguished: "Syncing data directory (fsync)" vs "Syncing data directory (syncfs)". + {"log_min_duration_startup_process", PGC_SUSET, LOGGING_WHEN, I think it should be PGC_SIGHUP, to allow changing it during runtime. Obviously it has no effect except during startup, but the change will be effective if the current process crashes. See also: https://www.postgresql.org/message-id/20210526001359.GE3676@telsasoft.com +extern void log_startup_process_progress(char *operation, void *data, + bool is_complete); I think this should take an enum operation, rather than using strcmp() on it later. The enum values might be RECOVERY_START, RECOVERY_END, rather than having a bool is_complete. -- Justin