Greetings,
* Stefan Kaltenbrunner (stefan@kaltenbrunner.cc) wrote:
> 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@lists.postgresql.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@lists.postgresql.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@lists.postgresql.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@lists.postgresql.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@lists.postgresql.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@lists.postgresql.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@lists.postgresql.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 :(
We have now taken the next step in 'optimization' and basically thrown a
bunch more hardware at the problem (well, and some other minor tuning,
but most of it was adding a bunch more CPUs). We will continue to keep
an eye on things, of course, and continue to tune but hopefully this
will help.
Thanks!
Stephen