From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6 |
Date: | 2019-05-07 14:50:19 |
Message-ID: | 28030.1557240619@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> I for sure thought I earlier had an idea that'd actually work. But
> either I've lost it, or it didn't actually work. But perhaps somebody
> else can come up with something based on the above strawman ideas?
Both of those ideas fail if an autovacuum starts up after you're
done looking. I still think the only way you could make this
reliable enough for the buildfarm is to do it in a TAP test that's
set up a cluster with autovacuum disabled. Whether it's worth the
cycles to do so is pretty unclear, since that wouldn't be a terribly
real-world test environment. (I also wonder whether the existing
TAP tests for reindexdb don't provide largely the same coverage.)
My advice is to let it go until we have time to work on getting rid
of the deadlock issues. If we're successful at that, it might be
possible to re-enable these tests in the regular regression environment.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-05-07 15:09:31 | Re: accounting for memory used for BufFile during hash joins |
Previous Message | Tom Lane | 2019-05-07 14:42:36 | Re: accounting for memory used for BufFile during hash joins |