Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sdw0c-002Nic-SP for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Aug 2024 18:12:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sdw0b-005T8X-7q for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Aug 2024 18:12:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sdw0a-005T8P-TM for pgsql-hackers@lists.postgresql.org; Tue, 13 Aug 2024 18:12:36 +0000 Received: from mail-qk1-x734.google.com ([2607:f8b0:4864:20::734]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sdw0Y-004gw5-I4 for pgsql-hackers@postgresql.org; Tue, 13 Aug 2024 18:12:36 +0000 Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-7a1d7bc07b7so386383785a.0 for ; Tue, 13 Aug 2024 11:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723572752; x=1724177552; darn=postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=kMEcR7c0S61O1Y74b/BTHUbhhXAgb4zy3GLbB1C2JRw=; b=XwlDtjjXKUZzUtdYe58OH+t8QIljIq0QBo3ZW/RaSn1yepg9bYrjG0tvqUryzuQLHu oUSvMMcYXZNHBvbJbha4SYTf4iGvgZNUei+8FtT+OGF66Dh3/pStz690DGc82k0cZAcK OVoLdvAXnTLw89+LDYJ+wBX19mRI5brhmUexWFPKV8UwRQXR/bi+/NIXH0tOmHBUIEZi BUT3NW2nvWy1pAYp5dNzf6dteJq9tVtadRzmXGETIrWwpYzJHYpkk7FiWlZR7gRAZ7p/ zg46GXj4n8B7ErJbgOrbRrVErAnbFQAnyJuXJ98tUNrW/sNysMnTw8SDSEOMsNTOhxjY kreA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723572752; x=1724177552; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kMEcR7c0S61O1Y74b/BTHUbhhXAgb4zy3GLbB1C2JRw=; b=PVnAXm8zUxcWupkMcyOlxgfdfRd0t9aOcDJVAt9mHkSV8GXr4jEg/6K5jB/pp2DLdV 6bAz+q63Om1eizyz92H3RA4LJH5niej8JkwSN5xhOoy1HjIL0zAyGYY4Qoq9M9eTC+cq fBk7kinnbTXLZTK5ZFDT0ksr2/12WQMa77RWw9rVYMt6rU/NKu+5miBJmzOcbUQcBJmP v18pKh2RtIcB9Xq43+CwGMP6RBAjCc7EfilVRtPNtcfGS/VNA8SZCbRwDgwUT8XEkIYV bFJ3gopZNqiBaR9XzAzYSvlQFvJXfeQHQZnfyjHcP/mo+eCrc021odevS2wxw1jJ1WAH QeBg== X-Forwarded-Encrypted: i=1; AJvYcCUte6HAfssH21AGw3u8Uz5CNG7Uj2yYJmhCKQVwmk9Fd0seSO1WSP9sfHIVf04bsVpboKULxw/iURc7Gcr94z1rIs3owxLWSNsRHRlI X-Gm-Message-State: AOJu0Yw8D5rcWD91osrBs9peNbU72SckYsedEZg+Fkgx/3VX9NT1wO36 bnJc75bCGrC0eq+fXkmqAPM3RbhQq5R/U6Fn0QNZ2/p5u36mY7UD X-Google-Smtp-Source: AGHT+IFziLXcv8ft7HR3lEe9HLl9fwOL+LNQxQTdVtwjL0OFftfygRm2/FJG4uZOV/0Ae642qz+DXw== X-Received: by 2002:a05:620a:469f:b0:79f:504:dead with SMTP id af79cd13be357-7a4ee3302f7mr52917985a.27.1723572752149; Tue, 13 Aug 2024 11:12:32 -0700 (PDT) Received: from [10.23.229.144] ([15.248.1.12]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7a4c7d64e8asm360677485a.18.2024.08.13.11.12.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Aug 2024 11:12:31 -0700 (PDT) Message-ID: Date: Tue, 13 Aug 2024 13:12:30 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Restart pg_usleep when interrupted To: Nathan Bossart Cc: Heikki Linnakangas , Bertrand Drouvot , Tom Lane , Robert Haas , "pgsql-hackers@postgresql.org" References: <2b5ac681-11d5-470d-af40-89ead9a868aa@gmail.com> <90ec1618-58db-46b3-8c9b-13616ac839a7@gmail.com> Content-Language: en-US From: "Imseih (AWS), Sami" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > None of this seems intractable to me. 1 Hz seems like an entirely > reasonable place to start, and it is very easy to change (or to even make > configurable). pg_stat_progress_vacuum might show slightly old values in > this column, but that should be easy enough to explain in the docs if we > are really concerned about it. If other callers want to do something > similar, maybe we should add a more generic implementation in > backend_progress.c. > I don't know if I agree. Making vacuum sleep more robust to handle interrupts seems like a cleaner general solution than to add even more code to handle this case or have to explain the behavior of cost delay instrumentation in docs. Regards, Sami