| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, "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 15:37:25 |
| Message-ID: | 1212538.1621957045@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> The problem disappears completely if I add a sleep to the cancel query:
> step "s1cancel" { SELECT pg_cancel_backend(pid), pg_sleep(0.01) FROM d3_pid; }
> I suppose a 0.01 second sleep is not going to be sufficient to close the
> problem in slower animals, but I hesitate to propose a much longer sleep
> because this test has 18 permutations so even a one second sleep adds
> quite a lot of (mostly useless) test runtime.
Yeah ... maybe 0.1 second is the right tradeoff?
Note that on slow (like CCA) animals, the extra query required by
Noah's suggestion is likely to take more than 0.1 second.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-05-25 15:46:05 | Re: Race condition in recovery? |
| Previous Message | Alvaro Herrera | 2021-05-25 15:32:38 | Re: Test of a partition with an incomplete detach has a timing issue |