| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, "'amitlangote09(at)gmail(dot)com'" <amitlangote09(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Test of a partition with an incomplete detach has a timing issue |
| Date: | 2021-05-25 00:46:58 |
| Message-ID: | YKxJAvXUr7uWXRHw@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yura Sokolov | 2021-05-25 00:58:43 | Re: Add PortalDrop in exec_execute_message |
| Previous Message | osumi.takamichi@fujitsu.com | 2021-05-25 00:42:34 | RE: Test of a partition with an incomplete detach has a timing issue |