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 1sNKQV-0080oi-4t for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Jun 2024 22:50:43 +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 1sNKQS-007Hdq-9W for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Jun 2024 22:50:40 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sNKQR-007Hdh-U7 for pgsql-hackers@lists.postgresql.org; Fri, 28 Jun 2024 22:50:40 +0000 Received: from mail-il1-x12e.google.com ([2607:f8b0:4864:20::12e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sNKQL-003cSo-3g for pgsql-hackers@postgresql.org; Fri, 28 Jun 2024 22:50:38 +0000 Received: by mail-il1-x12e.google.com with SMTP id e9e14a558f8ab-379c1f83db7so6924315ab.0 for ; Fri, 28 Jun 2024 15:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719615032; x=1720219832; darn=postgresql.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=254edRttNmrvUHWcx0I9G1nlXANbakN4PfeH2wOrw7k=; b=XLLJjyJm4j5hofEWKZsA+Ijia/zHYWdQTVd3NXuHCOyGJwl5gWqmPxswzBp/ghiM9h HHUcezhp85RmAqRfA/t23MHBfFB/pn1CC8b7/8nTQeI9LGxjfEkjKEyZjieGvDBEo7YT 2qvLTCJOh9tOafHhtd1TZ3CsxGocB/r7Qpe0W9vwLERvcOFaLtfJl8038Vr7ROP3wqxF 3WkvXtslhsV5ctKfAjdvvdeyRny1bTPmT/IjUfzuUYupWd8US3EHIz/HC81Yh3BsE+0j qIMayCBfRdOAU9jju/JTl8r2Xso4OetQB+66BoSDvC0hBOeIADtjHygj4zL+e7wFN/BG /7nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719615032; x=1720219832; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=254edRttNmrvUHWcx0I9G1nlXANbakN4PfeH2wOrw7k=; b=u3cSCPN4e7fopJ0q+z8TSK+J/+/1eHE7wBFQ7AL026lWLwx8xoa4qhTVwibZYAcNmd wZl7sfJy14JoN8g/bufpyenv9A+7W9Qgb0s192aqvuNn5wagZvzcCiTCuh83EUAw1KK+ xfbDAynftpJmPuQzl8bTjdv/5EcAHRdGaj+PuT5zTelFy7M5hrESBFN1Uo2BkEO05Qsl LIpFosESgEBHq7LRHfMnUDfANB/w+kCHX3Ga/dD2R/+SvfS+HzllKPSgAFsjy2coAHb4 B/YzqB9zNHxEA1if8mW8qbBI35IcQJGOdWtNjbRnoomtUFGRhfkD6y4YI26YkQXr+H0f NKyg== X-Forwarded-Encrypted: i=1; AJvYcCWP0mSa9u1zPDIpB6HpWqF5X0yieBymQGMzgkN0TrF66rwpZbNFNDlNCvlc9uecqaHpg7Dn20/54vNhjOU5RBo8j6gNI9OuU8+S0L4a X-Gm-Message-State: AOJu0YyxLvqNpivbKBZ4svnw4p789Extn9IDOu0Mb4oCaHosp9dBBNv2 a4YF/OZ3CAeFO7ZwIhV2YAhGhFiPmlpHi/mkUOzJnp/xdO4CZ7rH X-Google-Smtp-Source: AGHT+IEeCHLZY1hlu2EtJdsa8QCoM8TJbJZJNFBuqMvgPybtBmhUaHmlBNt0MwJYut7+9FnbMf20Qg== X-Received: by 2002:a92:7309:0:b0:375:daa0:ce46 with SMTP id e9e14a558f8ab-37b2bada407mr13214985ab.16.1719615032178; Fri, 28 Jun 2024 15:50:32 -0700 (PDT) Received: from smtpclient.apple (c-73-74-200-24.hsd1.il.comcast.net. [73.74.200.24]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4bb73bb3742sm762224173.15.2024.06.28.15.50.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2024 15:50:31 -0700 (PDT) From: Sami Imseih Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BE1CAC92-CCFA-492B-8012-E47092E0E01F" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Restart pg_usleep when interrupted Date: Fri, 28 Jun 2024 17:50:20 -0500 In-Reply-To: <2100439.1719610468@sss.pgh.pa.us> Cc: Robert Haas , "pgsql-hackers@postgresql.org" To: Tom Lane References: <152895F3-6B22-45ED-8038-9E14A72AAC88@amazon.com> <01000190606e3d2a-116ead16-84d2-4449-8d18-5053da66b1f4-000000@email.amazonses.com> <7D50DC5B-80C6-47B5-8DA8-A6C68A115EE5@gmail.com> <2100439.1719610468@sss.pgh.pa.us> X-Mailer: Apple Mail (2.3774.500.171.1.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_BE1CAC92-CCFA-492B-8012-E47092E0E01F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the feedback! > On Jun 28, 2024, at 4:34=E2=80=AFPM, Tom Lane = wrote: >=20 > Sami Imseih writes: >> Reattaching the patch. >=20 > I feel like this is fundamentally a wrong solution, for the reasons > cited in the comment for pg_usleep: long sleeps are a bad idea > because of the resulting uncertainty about whether we'll respond to > interrupts and such promptly. An example here is that if we get > a query cancel interrupt, we should probably not insist on finishing > out the current sleep before responding. The case which brought up this discussion is the pg_usleep that=20 is called within the vacuum_delay_point being interrupted.=20 When I read the same code comment you cited, it sounded to me=20 that =E2=80=9Clong sleeps=E2=80=9D are those that are in seconds or = minutes. The longest=20 vacuum delay allowed is 100ms. > Therefore, rather than "improving" pg_usleep (and uglifying its API), > the right answer is to fix parallel vacuum leaders to not depend on > pg_usleep in the first place. A better idea might be to use > pg_sleep() or equivalent code. Yes, that is a good idea to explore and it will not require introducing an awkward new API. I will look into using something similar to pg_sleep. Regards, Sami --Apple-Mail=_BE1CAC92-CCFA-492B-8012-E47092E0E01F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks for the = feedback!

On Jun 28, 2024, at 4:34=E2=80=AFPM, Tom Lane = <tgl@sss.pgh.pa.us> wrote:

Sami Imseih = <samimseih@gmail.com> writes:
Reattaching the patch.

I feel like = this is fundamentally a wrong solution, for the reasons
cited in the = comment for pg_usleep: long sleeps are a bad idea
because of the = resulting uncertainty about whether we'll respond to
interrupts and = such promptly.  An example here is that if we get
a query cancel = interrupt, we should probably not insist on finishing
out the current = sleep before = responding.

The = case which brought up this discussion is the pg_usleep = that 
is called within the vacuum_delay_point being = interrupted. 

When I read the same code = comment you cited, it sounded to me 
that =E2=80=9Clong = sleeps=E2=80=9D are those that are in seconds or minutes. The = longest 
vacuum delay allowed is = 100ms.


Therefore, rather than "improving" pg_usleep = (and uglifying its API),
the right answer is to fix parallel vacuum = leaders to not depend on
pg_usleep in the first place.  A better = idea might be to use
pg_sleep() or equivalent = code.

Yes, that is a = good idea to explore and it will not require introducing
an = awkward new API. I will look into using something similar = to
pg_sleep.

Regards,

Sami


= --Apple-Mail=_BE1CAC92-CCFA-492B-8012-E47092E0E01F--