Re: Slower bounce-back of commit messages

On 11/14/18 10:52 PM, Tom Lane wrote:
> It seems like sometime in the past few days, the throughput of the
> PG mail system dropped substantially. The particular symptom I'm
> noticing is that when I push multiple commits, it used to be
> that the pgsql-committers traffic came back (a) within a few seconds
> and (b) all together. Now it takes a few minutes for them to trickle in,
> as in this example of seven commits that were pushed together:
>
> From pgsql-committers-owner+M15-102287(at)lists(dot)postgresql(dot)org Wed Nov 14 16:40:31 2018
> Subject: pgsql: Doc: remove claim that all \pset format options are unique in
> From pgsql-committers-owner+M15-102288(at)lists(dot)postgresql(dot)org Wed Nov 14 16:40:35 2018
> Subject: pgsql: Doc: remove claim that all \pset format options are unique in
> From pgsql-committers-owner+M15-102292(at)lists(dot)postgresql(dot)org Wed Nov 14 16:43:57 2018
> Subject: pgsql: Doc: remove claim that all \pset format options are unique in
> From pgsql-committers-owner+M15-102289(at)lists(dot)postgresql(dot)org Wed Nov 14 16:44:20 2018
> Subject: pgsql: Doc: remove claim that all \pset format options are unique in
> From pgsql-committers-owner+M15-102290(at)lists(dot)postgresql(dot)org Wed Nov 14 16:44:34 2018
> Subject: pgsql: Doc: remove claim that all \pset format options are unique in
> From pgsql-committers-owner+M15-102293(at)lists(dot)postgresql(dot)org Wed Nov 14 16:44:43 2018
> Subject: pgsql: Make psql's "\pset format" command reject non-unique
> From pgsql-committers-owner+M15-102291(at)lists(dot)postgresql(dot)org Wed Nov 14 16:44:52 2018
> Subject: pgsql: Doc: remove claim that all \pset format options are unique in
>
> I've also noticed slower turnaround on some of the other lists.
> What's up?

we have recently spent a fair amount of effort in optimizing delivery
times for large delivery bursts (especially concurrent approvals for
mails on -announce) which caused very large load on the emailinglist box
and way too aggressive backoff in delivery afterwards.
That aggressive backoff caused excessive delays for a very large number
of recipients - the current setup copes with that scenario much better
however it puts deliveries for smaller lists (like pgsql-committers) at
a disadvantage because we stepping down aggressive deliveries a little
bit too early.
We are still working on further refining the system but as with every
optimization if you optimize for one scenario you might put another one
at a disadvantage :(

Stefan