Re: Using contrib modules in check (Re: pgsql: Fix BRIN to use SnapshotAny during summarization)
От | Tom Lane |
---|---|
Тема | Re: Using contrib modules in check (Re: pgsql: Fix BRIN to use SnapshotAny during summarization) |
Дата | |
Msg-id | 2713.1439215712@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Using contrib modules in check (Re: pgsql: Fix BRIN to use SnapshotAny during summarization) (Christoph Berg <myon@debian.org>) |
Ответы |
Re: Using contrib modules in check (Re: pgsql: Fix BRIN
to use SnapshotAny during summarization)
|
Список | pgsql-committers |
Christoph Berg <myon@debian.org> writes: > Re: Tom Lane 2015-08-07 <928.1438900846@sss.pgh.pa.us> >> I don't really think we need this isolation test at all, but if we do, >> please fix it to not rely on any extensions. Perhaps looking at >> pg_relation_size or some such would do? Or you could just issue >> a query that should use the index, and see if it finds the rows it >> ought to. > this breaks the Debian package builds as well because we run > check-world as a build step. > Any chance for a fix/workaround so the nightly master/head builds will > succeed again? I was waiting for Alvaro to deal with this, but perhaps he's on summer vacation or something. I will remove the isolation test until he has time to address it more fully. However, we did learn something valuable from the fact that all the -DCLOBBER_CACHE_ALWAYS critters failed on it: per my earlier message, brin_page_items() is unsafe against a relcache flush on the index. I'll put that on the 9.5 open items list. (If I were tasked with fixing it, I'd be tempted to rewrite it to do all the work in one call and return a tuplestore; the alternative seems to be to try to keep the index open across multiple calls, which would be a mess.) regards, tom lane
В списке pgsql-committers по дате отправления: