Re: test/modules/test_oat_hooks vs. debug_discard_caches=1

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: test/modules/test_oat_hooks vs. debug_discard_caches=1
Date: 2022-11-19 15:30:40
Message-ID: e20bb3bb-3d2f-5221-59d4-b3ecb5a82a5d@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2022-11-19 Sa 09:33, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
>> On 11/19/22 14:51, Andrew Dunstan wrote:
>>> On 2022-11-19 Sa 05:34, Tomas Vondra wrote:
>>>> I wonder if it'd make sense to have some simple & optional alerting
>>>> based on how long ago the machine reported the last result. Send e-mail
>>>> if there was no report for a month or so would be enough.
>>> This has been part of the buildfarm for a very long time. See the alerts
>>> section of the config file.
>> I don't think alerting from the client would catch those cases, but
>> maybe it's a rare issue and I'm overthinking it.
> Those alerts are sent by the buildfarm server, not the client.
>
> That has a failure mode of its own: if an animal goes down hard,
> the server is left with its last-seen alert setup. The only
> way to not get nagged permanently is to ask Andrew to intervene
> manually. (Ask me how I know.)
>
>

True for now. The next release will have a utility command to
disable/enable alerts. The required server changes have already been made.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-11-19 15:56:33 Re: ssl tests aren't concurrency safe due to get_free_port()
Previous Message Tom Lane 2022-11-19 14:33:22 Re: test/modules/test_oat_hooks vs. debug_discard_caches=1