From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Missed check for too-many-children in bgworker spawning |
Date: | 2019-11-04 17:29:50 |
Message-ID: | 20191104172950.GA31048@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-Nov-04, Robert Haas wrote:
> On Mon, Nov 4, 2019 at 10:42 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > > True, it's not a situation you especially want to be in. However,
> > > I've lost count of the number of times that I've heard someone talk
> > > about how their system was overstressed to the point that everything
> > > else was failing, but Postgres kept chugging along. That's a good
> > > reputation to have and we shouldn't just walk away from it.
> >
> > I agree with this point in principle. Everything else (queries,
> > checkpointing) can fail, but it's critical that postmaster continues to
> > run [...]
>
> Sure, I'm not arguing that the postmaster should blow up and die.
I must have misinterpreted you, then. But then I also misinterpreted
Tom, because I thought it was this stability problem that was "utter
bunkum".
> I was, however, arguing that if the postmaster fails to launch workers
> for a parallel query due to process table exhaustion, it's OK for
> *that query* to error out.
That position makes sense to me. It would be nice [..ponies..] for the
query to run regardless, but if it doesn't, it's not such a big deal;
the query could have equally failed to run in a single process anyway.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Verite | 2019-11-04 17:41:59 | Re: updating unaccent.rules for Arabic letters |
Previous Message | Tom Lane | 2019-11-04 17:18:48 | Re: Excessive disk usage in WindowAgg |