Re: changing MyDatabaseId

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: changing MyDatabaseId
Date: 2010-11-17 12:57:18
Message-ID: 4CE3D12E.2060507@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/17/2010 01:27 PM, Alvaro Herrera wrote:
> I don't think it's a speed thing only. It would be a great thing to
> have in autovacuum, for example, where we have constant problem reports
> because the system failed to fork a new backend. If we could simply
> reuse an already existing one, it would be a lot more robust.

Hm, that's an interesting point.

To actually increase robustness, it would have to be a failure scenario
that (temporarily) prevents forking, but allows an existing backend to
continue to do work (i.e. the ability to allocate memory or open files
come to mind).

Any idea about what's usually causing these fork() failures? I'm asking
because I'm afraid that for example, in case of an out of memory
condition, we'd just hit an OOM error later on, without being able to
perform the VACUUM job, either.

Regards

Markus Wanner

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc Cousin 2010-11-17 13:13:55 Review: rollback sequence reset for TRUNCATE ... RESTART IDENTITY
Previous Message Alvaro Herrera 2010-11-17 12:27:06 Re: changing MyDatabaseId