On 2014-07-22 22:18:03 +0900, MauMau wrote: > From: "Andres Freund" <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers