On Tue, May 25, 2021 at 11:32:38AM -0400, Alvaro Herrera wrote:
> On 2021-May-24, Noah Misch wrote:
> > What if we had a standard that the step after the cancel shall send a query
> > to
> > the backend that just received the cancel? Something like:
>
> Hmm ... I don't understand why this fixes
On 2021-May-25, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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 h
So I had a hard time reproducing the problem, until I realized that I
needed to limit the server to use only one CPU, and in addition run some
other stuff concurrently in the same server in order to keep it busy.
With that, I see about one failure every 10 runs.
So I start the server as "numactl -
On Mon, May 24, 2021 at 09:12:40PM -0400, Tom Lane wrote:
> The experiments I did awhile ago are coming back to me now. I tried
> a number of variations on this same theme, and none of them closed
> the gap entirely. The fundamental problem is that it's possible
> for backend A to complete its tr
Michael Paquier writes:
> On Mon, May 24, 2021 at 02:07:12PM -0400, Alvaro Herrera wrote:
>> 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" col
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), someh
On Tuesday, May 25, 2021 3:07 AM Alvaro Herrera wrote:
> On 2021-May-24, osumi.takami...@fujitsu.com wrote:
>
> > Also, I've gotten some logs left.
> > * src/test/isolation/output_iso/regression.out
> >
> > test detach-partition-concurrently-1 ... ok 682 ms
> > test detach-partition-conc
Alvaro Herrera writes:
> On 2021-May-24, osumi.takami...@fujitsu.com wrote:
>> t
>> -step s2detach: <... completed>
>> -error in steps s1cancel s2detach: ERROR: canceling statement due to user
>> request
>> step s1c: COMMIT;
>> +step s2detach: <... completed>
>> +error in steps s1c
On 2021-May-24, osumi.takami...@fujitsu.com wrote:
> Also, I've gotten some logs left.
> * src/test/isolation/output_iso/regression.out
>
> test detach-partition-concurrently-1 ... ok 682 ms
> test detach-partition-concurrently-2 ... ok 321 ms
> test detach-partition-concurrentl
10 matches
Mail list logo
