|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Christoph Berg <myon(at)debian(dot)org>|
|Cc:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-committers(at)postgresql(dot)org|
|Subject:||Re: Using contrib modules in check (Re: pgsql: Fix BRIN to use SnapshotAny during summarization)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Christoph Berg <myon(at)debian(dot)org> writes:
> Re: Tom Lane 2015-08-07 <928(dot)1438900846(at)sss(dot)pgh(dot)pa(dot)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
|Next Message||Andres Freund||2015-08-10 14:12:54||Re: replication slot restart_lsn initialization|
|Previous Message||Tom Lane||2015-08-10 13:55:01||Re: tap tests remove working directories|
|Next Message||Tom Lane||2015-08-10 14:22:55||pgsql: Temporarily(?) remove BRIN isolation test.|
|Previous Message||Andres Freund||2015-08-10 11:29:24||pgsql: Fix copy & paste mistake in pg_get_replication_slots().|