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 1mVdeE-0004MO-H2 for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Sep 2021 17:45:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mVdeD-00083E-G1 for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Sep 2021 17:45:37 +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 1mVdeD-000836-3e for pgsql-hackers@lists.postgresql.org; Wed, 29 Sep 2021 17:45:37 +0000 Received: from mail-il1-x12c.google.com ([2607:f8b0:4864:20::12c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mVde9-0004sO-Ul for pgsql-hackers@postgresql.org; Wed, 29 Sep 2021 17:45:36 +0000 Received: by mail-il1-x12c.google.com with SMTP id r9so3776792ile.5 for ; Wed, 29 Sep 2021 10:45:33 -0700 (PDT) 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:in-reply-to:user-agent; bh=0Qv24GFTBY8secYvPYjoqxHDwy/qyfQn2dt5Fdh5Zj0=; b=Z0EwwsG62UdEPqhla2y7PTsDJhtGijQfgLSb0otKbVgUwQBH9Sxj6Erf08JkVvEZOc Ar9828tB9EwSn3sZHRUMRk64pvvYS+Qw1cs9v52dhGdSeZSiLY0xtiElVGTqsP9fiLRW bHSTbfF54n2Dy730FjylfGFsBFmhgM0pp5LD+DQ3P+hJ8xiDSFLr3iIZv1xKt1Z6/c92 vK0tZT4llGTkhinTAv+jjL5UdYSCvUfkv5l43MHPpjrUmp2uXkgA6GdEFa32ZaFI4RHD 4i/c04voFarlx5OHSwAFsqFmXb2cEZapgnBKGjNXq0nWgtnZ9JRqXBTcLafxub1F6hgp LNHQ== 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:in-reply-to:user-agent; bh=0Qv24GFTBY8secYvPYjoqxHDwy/qyfQn2dt5Fdh5Zj0=; b=O499h8JEEpz7/USPaS/cp8aOjf+zDmVY4XED7Edy5XdGn6RjXso2uN8V8Gj1eVYV33 Q8zOB1w5PdNugDfCYk5LLKSnrKaBW5gY1cWWwY4L8snMq8B7AZkJ7DQfxnE2RSvLDxuR hJNJMj1pTQAapIfCee0bpN/TvH3l0th93qLTpmQWFnSsNOlzD8hcEfAMaf0ai5JqjIVW 11rGKMYS5xoKB9EYO3h1qldXki2XX7NIMv9Ew7MQGMjmIu4d0OY4MHE8WA64XF64PwfY d8Y0icwVbrs9nuPkBRS6vW90fWP9NMyQhkdmJdKRHwkL1TYdiQBcLcPtePyD6c1AjBqZ ToEA== X-Gm-Message-State: AOAM532jWvDLEitU4BCYlXMzyBiH29qkvQGuJwUuhuNWlTa7MTR2KCmq 3o3C9F8XFaXGNjTTD//aToxf2Q== X-Google-Smtp-Source: ABdhPJw2sU0grRw3eLbaPISpsRTiq03GY6S6J0nA8UTEj5KD8o8C0HouOK9R8BY9s4wBjb/AYvqY8w== X-Received: by 2002:a05:6e02:f94:: with SMTP id v20mr754998ilo.148.1632937532045; Wed, 29 Sep 2021 10:45:32 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id o1sm299293ilj.41.2021.09.29.10.45.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Sep 2021 10:45:31 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 951798009E1; Wed, 29 Sep 2021 12:45:30 -0500 (CDT) Date: Wed, 29 Sep 2021 12:45:30 -0500 From: Justin Pryzby To: Alvaro Herrera Cc: Nitin Jadhav , Robert Haas , Michael Paquier , Bharath Rupireddy , Tom Lane , Andres Freund , Stephen Frost , Magnus Hagander , Thomas Munro , "pgsql-hackers@postgresql.org" Subject: Re: when the startup process doesn't (logging startup delays) Message-ID: <20210929174530.GK831@telsasoft.com> References: <202109291736.w3lzq4prep3p@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202109291736.w3lzq4prep3p@alvherre.pgsql> 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, Sep 29, 2021 at 02:36:14PM -0300, Alvaro Herrera wrote: > Why is it that we set the next timeout to fire not at "now + interval" > but at "when-it-should-have-fired-but-didn't + interval"? As a user, if > I request a message to be logged every N milliseconds, and one > of them is a little bit delayed, then (assuming I set it to 10s) I still > expect the next one to occur at now+10s. I don't expect the next at > "now+5s" if one is delayed 5s. > > In other words, I think this function should just be > enable_timeout_after(STARTUP_PROGRESS_TIMEOUT, log_startup_progress_interval); > > This means you can remove the scheduled_startup_progress_timeout > variable. Robert requested the current behavior here. https://www.postgresql.org/message-id/CA%2BTgmoYkS1ZeWdSMFMBecMNxWonHk6J5eoX4FEQrpKtvEbXqGQ%40mail.gmail.com It's confusing (at least) to get these kind of requests to change the behavior back and forth. -- Justin