| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: We're leaking predicate locks in HEAD |
| Date: | 2019-05-07 19:55:23 |
| Message-ID: | 2960.1557258923@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On 5/7/19 1:46 PM, Tom Lane wrote:
>> After running the core regression tests with installcheck-parallel,
>> the pg_locks view sometimes shows me apparently-orphaned SIReadLock
>> entries. They accumulate over repeated test runs.
> Should we have a test for that run at/near the end of the regression
> tests? The buildfarm will actually do multiple runs like this if set up
> to do parallel checks and test multiple locales.
No, I'm not excited about that idea; I think it'd have all the same
fragility as the late lamented "REINDEX pg_class" test. A given test
script has no business assuming that other test scripts aren't
legitimately taking out predicate locks, nor assuming that prior test
scripts are fully cleaned up when it runs.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-05-07 20:16:19 | Re: [HACKERS] Detrimental performance impact of ringbuffers on performance |
| Previous Message | Andrew Dunstan | 2019-05-07 19:50:26 | Re: We're leaking predicate locks in HEAD |