| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution. |
| Date: | 2016-02-11 17:04:39 |
| Message-ID: | 20201.1455210279@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
I wrote:
> No, because the machines that are failing are showing a "<waiting ...>"
> annotation that your reference output *doesn't* have. I think what is
> actually happening is that these machines are seeing the process as
> waiting and reporting it, whereas on your machine the backend detects
> the deadlock and completes the query (with an error) before
> isolationtester realizes that the process is waiting.
I confirmed this theory by the expedient of changing the '10ms' setting
in the test script to 1ms (which worked) and 100ms (which did not, on
the same machine).
I've committed an update that adjusts the timeouts to hopefully ensure
that isolationtester always sees the query as blocked before the deadlock
detector unblocks it; which seems like the behavior we want to test for,
anyway.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-02-11 17:11:26 | Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution. |
| Previous Message | Tom Lane | 2016-02-11 16:59:17 | pgsql: Make new deadlock isolation test more reproducible. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2016-02-11 17:10:23 | Re: [PATCH] Refactoring of LWLock tranches |
| Previous Message | Anastasia Lubennikova | 2016-02-11 16:46:24 | Re: WIP: Covering + unique indexes. |