Re: Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS
Date
Msg-id 10351.1418661040@sss.pgh.pa.us
Whole thread Raw
In response to Re: Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-12-15 10:15:30 -0500, Tom Lane wrote:
>> The CLOBBER_CACHE_ALWAYS buildfarm members occasionally fail in
>> contrib/test_decoding with
>> TRAP: FailedAssertion("!(((bool)((relation)->rd_refcnt == 0)))", File: "relcache.c", Line: 1981)

> Without catchup invalidations and/or an outside reference to a relation
> that's normally not a problem because it won't get reloaded from the
> caches at an inappropriate time while invisible. Until a few weeks ago
> there was no regression test covering that case which is why these
> crashes are only there now.

I've always thought that this whole idea of allowing the caches to contain
stale information was a Rube Goldberg plan that was going to bite you on
the ass eventually.  This case isn't doing anything to increase my faith
in it, and the proposed patch seems like just another kluge on top of
a rickety stack.

I think the safest fix would be to defer catchup interrupt processing
while you're in this mode.  You don't really want to be processing any
remote sinval messages at all, I'd think.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgbench -f and vacuum
Next
From: Robert Haas
Date:
Subject: Re: Making BackgroundWorkerHandle a complete type or offering a worker enumeration API?