Re: Out of Memory - 8.2.4

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Jeff Amiel <becauseimjeff(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Out of Memory - 8.2.4
Date: 2007-09-01 01:53:43
Message-ID: 20070901015343.GW8046@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane escribió:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > It continues with the next table if interrupted (SIGINT), but the worker
> > exits on any other error. I would ask you to review that code -- it's
> > in do_autovacuum, the PG_TRY block at the end. It was committed in rev
> > 1.52 of autovacuum.c.
>
> While looking at this I came across something I didn't like at all:
>
> * We somewhat ignore the risk that the launcher changes its PID
> * between we reading it and the actual kill; we expect ProcKill to be
> * called shortly after us, and we assume that PIDs are not reused too
> * quickly after a process exits.
>
> I'm fairly sure that Windows has a bad habit of recycling PIDs almost
> immediately. I didn't actually read the code to see what the assumption
> is for --- I just noticed this comment and it set off alarm bells.

Well, this is not much of a risk, because what's going on is that the
worker wants to signal the launcher. So the launcher would need to shut
down for this to happen, which would be pretty rare on its own. Also,
note that the time interval we're talking about is between one proc_exit
handler fires and the next.

Also, note that the worst thing that can happen is that the wrong
process gets a SIGUSR1 signal, and the launcher misses an opportunity
for starting another worker and rebalancing the vacuum cost parameters.

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"No me acuerdo, pero no es cierto. No es cierto, y si fuera cierto,
no me acuerdo." (Augusto Pinochet a una corte de justicia)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-09-01 02:14:06 Re: Out of Memory - 8.2.4
Previous Message Tom Lane 2007-09-01 01:11:52 Re: Out of Memory - 8.2.4