From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | chap(at)anastigmatix(dot)net, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: test/isolation/expected/stats_1.out broken for me |
Date: | 2022-04-08 01:22:57 |
Message-ID: | 20220408012257.q3bp2rdbewg23wpr@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-04-07 18:31:35 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2022-04-07 09:57:09 -0700, Andres Freund wrote:
> >> Yea :(. I tested debug_discard_caches, but not -DRELCACHE_FORCE_RELEASE
> >> -DCATCACHE_FORCE_RELEASE.
> >>
> >> Not quite sure what to do about it - it's intentionally trying to test the
> >> case of no invalidations being processed, as that's an annoying edge case with
> >> functions. Perhaps wrapping the function call of the "already dropped"
> >> function in another function that catches the error would do the trick? It'd
> >> be more easily silently broken, but still be better than not having the test.
>
> > Anybody got a better idea?
>
> Maybe if the wrapper function checks for exactly the two expected
> behaviors, it'd be robust enough?
Seems to work. If I break the code it's trying to test, it still fails... Of
course only when none of debug_discard_caches, RELCACHE_FORCE_RELEASE,
CATCACHE_FORCE_RELEASE are used, but that seems unavoidable / harmless. Let's
see what the buildfarm thinks.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-04-08 01:32:55 | Re: API stability |
Previous Message | chap | 2022-04-08 01:22:11 | Re: Documentation about PL transforms |