Attachment protected by Amazon: [0001-Handle-Sleep-interrupts.patch] https://us-east-1.secure-attach.amazon.com/fcdc82ce-7887-4aa1-af9e-c1161a6b1d6f/bc81fa24-41de-48f9-a767-a6d15801754b
Amazon has replaced attachment with download link. Downloads will be available until July 28, 2024, 19:59 (UTC+00:00). [Tell us what you think] https://amazonexteu.qualtrics.com/jfe/form/SV_ehuz6zGo8YnsRKK [For more information click here] https://docs.secure-attach.amazon.com/guide Hi, In the proposal by Bertrand [1] to implement vacuum cost delay tracking in pg_stat_progress_vacuum, it was discovered that the vacuum cost delay ends early on the leader process of a parallel vacuum due to parallel workers reporting progress on index vacuuming, which was introduced in 17 with commit [2]. With this patch, everytime a parallel worker completes a vacuum index, it will send a completion message to the leader. The facility that allows a parallel worker to report progress to the leader was introduced in commit [3]. In the case of the patch being proposed by Bertrand, the number of interrupts will be much more frequent as parallel workers would send a message to the leader to update the vacuum delay counters every vacuum_delay_point call. Looking into this, the ideal solution appears to provide the ability for a pg_usleep call to restart after being interrupted. Thanks to the usage of nanosleep as of commit[4], this should be trivial to do as nanosleep provides a remaining time, which can be used to restart the sleep. This idea was also mentioned in [5]. I am attaching a POC patch that does the $SUBJECT. Rather than changing the existing pg_usleep, the patch introduces a function, pg_usleep_handle_interrupt, that takes in the sleep duration and a boolean flag to force handling of the interrupt, or not. This function can replace pg_usleep inside vacuum_delay_point, and could be useful in other cases in which it’s important to handle interrupts. For Windows, the “force” = “true” flag of the new function uses SleepEx which from what I can tell based on the code comments is a non-interruptible sleep. Thoughts? [1] https://www.postgresql.org/message-id/ZnbIIUQpFJKAJx2W%40ip-10-97-1-34.eu-west-3.compute.internal [2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=46ebdfe164c61fbac961d1eb7f40e9a684289ae6 [3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f1889729dd3ab0352dc0ccc2ffcc1b1901f8e39f [4] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a948e49e2ef11815be0b211723bfc5b53b7f75a8 [5] https://www.postgresql.org/message-id/24848.1473607575%40sss.pgh.pa.us Regards, Sami Imseih Amazon Web Services (AWS)
