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 1pL8m7-0004AB-QM for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jan 2023 20:23:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pL8m6-0004vC-6s for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Jan 2023 20:23:10 +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 1pL8m5-0004v3-Sw for pgsql-hackers@lists.postgresql.org; Thu, 26 Jan 2023 20:23:09 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pL8m2-0004Y7-4G for pgsql-hackers@postgresql.org; Thu, 26 Jan 2023 20:23:09 +0000 Received: by mail-pj1-x102f.google.com with SMTP id lp10so2606321pjb.4 for ; Thu, 26 Jan 2023 12:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=majCJ46l0hzI6WZH4V3yGM89uaLEwQkim2uk4ZK9VEE=; b=D9qfXq1p1DXa/xvS/ib8ght17ZrYA8yIHWuoyKW75HszkLlDZEg3GQqLjZOaI3eM/d ZEYVJowFJ1/Yyfd4YGEvk6U51M26IwYssTWmNKvsOUvMWD/IdaXwAsBLm7D2adHhdZ5g J7XNfH5GM82tNW+TM4QlbY5Z7/GwF8TTYkZyrRY7mIofqEp05ujblwciWwnSfTRfWssQ yAmRJIB0tTPDH94TUGGYjqJuXSrxgow4aLWcWha95/stvlt/n3xd8mX6+mhRIFpV6ESH BVEF/mx66evYtnLFytSFymC0ZjQ5X6fFUrOfIwmiSJbh04isCIvamw9yYX9wcvHwbk2x brMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=majCJ46l0hzI6WZH4V3yGM89uaLEwQkim2uk4ZK9VEE=; b=eOj0C/5za6J4FG/t899R8ocpZeUXMO7NUV7XQheVGgZPV5+K1jS+ug7qWxeN+fIUwn terBFqJvt0Ul4teHQK3BurTKrhkwGEf1YK+gxwL/+UAlhChXT/soQjOqBdj9NMpKOTCt lg69/oPHvQSICtepJaCsbNT7QKAHq0HZz74A/DtG0DmN+NQBN068OGOFBc0slNa9jzQY qqzRD6LDEzx4fkuPJn+YSHrA4yJu+FxODXelDM0ybRijxwSNSL2fG0hDZIIWaw9/VyON ullhb6sIYg1sqOZWmSmHotHC+xf9YP+d8Rh3Jz+m+65t7hIDKKkwtkDFnc1BBukAphm5 6sjg== X-Gm-Message-State: AFqh2kp4N8fmO+/0mqD4BfSNH1FqeA8uCWx5E9masiTuep8OHivMTtin mRDFFKwfgDIeoWQSVecg54c= X-Google-Smtp-Source: AMrXdXuIoAfV0bl9DLa1rgaZ2Wx+gD8VLp/L6qQdcEo3dfp4nqQS6yh+Nposmg7jXkMkeVfgD+W+vA== X-Received: by 2002:a05:6a20:2d10:b0:b9:33f3:1dc2 with SMTP id g16-20020a056a202d1000b000b933f31dc2mr31064642pzl.11.1674764583855; Thu, 26 Jan 2023 12:23:03 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id ds1-20020a17090b08c100b00212e5068e17sm1458226pjb.40.2023.01.26.12.23.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Jan 2023 12:23:03 -0800 (PST) Date: Thu, 26 Jan 2023 12:23:01 -0800 From: Nathan Bossart To: Tom Lane Cc: Thomas Munro , "Hayato Kuroda (Fujitsu)" , "pgsql-hackers@postgresql.org" Subject: Re: suppressing useless wakeups in logical/worker.c Message-ID: <20230126202301.GA1703463@nathanxps13> References: <2557815.1674603908@sss.pgh.pa.us> <20230125235004.GA1327755@nathanxps13> <20230126003319.GA1507251@nathanxps13> <2878152.1674700077@sss.pgh.pa.us> <2888102.1674705840@sss.pgh.pa.us> <3126727.1674759248@sss.pgh.pa.us> <20230126194812.GA1702315@nathanxps13> <3165443.1674763470@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3165443.1674763470@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Jan 26, 2023 at 03:04:30PM -0500, Tom Lane wrote: > Nathan Bossart writes: >> I wonder if we should explicitly reject negative timestamps to eliminate >> any chance of int64 overflow, too. > > Hmm. I'm disinclined to add an assumption that the epoch is in the past, > but I take your point that the subtraction would overflow with > TIMESTAMP_INFINITY and a negative finite timestamp. Maybe we should > make use of pg_sub_s64_overflow()? That would be my vote. I think the 'diff <= 0' check might need to be replaced with something like 'start_time > stop_time' so that we return 0 for the underflow case. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com