Re: Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Something is broken in logical decoding with CLOBBER_CACHE_ALWAYS
Date: 2014-12-15 16:30:40
Message-ID: 10351.1418661040@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-12-15 16:31:20 Re: Making BackgroundWorkerHandle a complete type or offering a worker enumeration API?
Previous Message Robert Haas 2014-12-15 16:29:26 Re: pgbench -f and vacuum