Re: Out of Memory - 8.2.4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
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:11:52
Message-ID: 5450.1188609112@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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. Can
you rework the logic to not depend on PIDs at all? (Perhaps the
"session IDs" that Florian's patch will create would serve instead?
I imagine those will be assigned during InitProcess, so they should
be available to identify individual autovac workers.)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2007-09-01 01:53:43 Re: Out of Memory - 8.2.4
Previous Message Darek Czarkowski 2007-09-01 01:11:02 Postgresql 7.3 on Red Hat Enterprise 5 (Problem with SEMMNI, SEMMNS)