On 2014-07-22 22:18:03 +0900, MauMau wrote:
> From: "Andres Freund" <andres@2ndquadrant.com>
> >On 2014-07-22 19:13:56 +0900, MauMau wrote:
> >>But this is true if restart_after_crash = on in postgresql.conf, because
> >>the
> >>crash restart only occurs in that case. However, in HA cluster, whether
> >>it
> >>is shared-disk or replication, restart_after_crash is set to off, isn't
> >>it?
> >
> >In almost all setups I've seen it's set to on, even in HA scenarios.
>
> I'm afraid that's because people don't notice the existence or purpose of
> this parameter. The 9.1 release note says:
I think it's also because it's simply a good idea to keep it on in many
production scenarios. Failing over 'just' because something caused a
crash restart is often too expensive.
> >No. Just removing a warning isn't the way to solve this. If you want to
> >improve things you'll actually need to improve things not just stick
> >your head into the sand.
> I have a few ideas below, but none of them seems better than the original
> proposal. What do you think?
> 1. startup process deletes the catalog entries and data files of leftover
> temp relations at the end of recovery.
> This is probably difficult, impossible or undesirable, because the startup
> process cannot access system catalogs. Even if it's possible, it is against
> the developers' desire to leave temp relation files for debugging.
>
> 2. autovacuum launcher deletes the catalog entries and data files of
> leftover temp relations during its initialization.
> This may be possible, but it is against the developers' desire to leave temp
> relation files for debugging.
I think that desire is pretty much antiquated and doesn't really count
for much.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services