Re: suppress automatic recovery after back crash

On Sun, Jun 27, 2010 at 9:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jun 17, 2010 at 7:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Then all you need is a tweak to make the postmaster exit(1) after
>>> a crash instead of trying to launch recovery.
>
>> This seems useful to me so here's a patch to implement it.
>
> Hm, is it useful in the absence of the other components of the proposed
> feature?

I think so. People are already using PostgreSQL as a feature-rich
cache; the point of the other changes Josh mentioned is just to make
it more performant. Specifically, he mentioned: (a) Eliminate WAL
logging entirely, (b) Eliminate checkpointing, and (c) Turn off the
background writer. I'm worked on unlogged tables, which will take us
about as far as we're likely to go in the direction of (a), per the
discussion on -performance. I haven't thought too much about (b) and
(c) so I'm not sure how involved that is, or how far we get just by
setting bgwriter_lru_maxpagess=0 as Greg Smith suggested, but, again,
it's just a performance optimization of something people are already
doing.

> One stylistic gripe:
>
> @@ -80,6 +80,7 @@ enum config_group
>        COMPAT_OPTIONS,
>        COMPAT_OPTIONS_PREVIOUS,
>        COMPAT_OPTIONS_CLIENT,
> +       ERROR_HANDLING,
>        PRESET_OPTIONS,
>        CUSTOM_OPTIONS,
>        DEVELOPER_OPTIONS
>
> Please spell that "ERROR_HANDLING_OPTIONS", both for consistency with
> the other enum members and to avoid likely conflicts with other uses of
> such a generic-looking identifier.

I mulled over which of those names was better; updated version,
reflecting your proposed naming, attached.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company