Re: Test of a partition with an incomplete detach has a timing issue

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>, "'amitlangote09@gmail.com'" <amitlangote09@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-25T00:46:58Z
Lists: pgsql-hackers
On Mon, May 24, 2021 at 02:07:12PM -0400, Alvaro Herrera wrote:
> I suppose a fix would imply that the error report waits until after the
> "cancel" step is over, but I'm not sure how to do that.
> 
> Maybe we can change the "cancel" query to something like
> 
> SELECT pg_cancel_backend(pid), somehow_wait_for_detach_to_terminate() FROM d3_pid;
> 
> ... where maybe that function can check the "state" column in s3's
> pg_stat_activity row?  I'll give that a try.

Couldn't you achieve that with a small PL function in a way similar to
what 32a9c0b did, except that you track a different state in
pg_stat_activity for this PID?
--
Michael

Commits

  1. Make detach-partition-concurrently-3 less timing-sensitive