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
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) |