Re: Out of Memory - 8.2.4 - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: Out of Memory - 8.2.4
Date
Msg-id 20070901015343.GW8046@alvh.no-ip.org
Whole thread Raw
In response to Re: Out of Memory - 8.2.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Out of Memory - 8.2.4
List pgsql-general
Tom Lane escribió:
> Alvaro Herrera <alvherre@commandprompt.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)

pgsql-general by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: computing and updating the size of a table with large objects
Next
From: Tom Lane
Date:
Subject: Re: Out of Memory - 8.2.4