On 2014-08-12 11:56:41 -0400, Robert Haas wrote:
> On Tue, Aug 12, 2014 at 11:06 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-08-12 11:04:00 -0400, Robert Haas wrote:
> >> On Mon, Aug 11, 2014 at 7:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> > Robert Haas <robertmhaas@gmail.com> writes:
> >> >> On Fri, Aug 8, 2014 at 10:30 AM, MauMau <maumau307@gmail.com> wrote:
> >> >>> I've tracked down the real root cause. The fix is very simple. Please
> >> >>> check the attached one-liner patch.
> >> >
> >> >> I'd support back-porting that commit to 9.1 and 9.2 as a fix for this
> >> >> problem. As the commit message says, it's dead simple.
> >> >
> >> > While I have no great objection to back-porting Heikki's patch, it seems
> >> > like a very large stretch to call this a root-cause fix. At best it's
> >> > band-aiding one symptom in a rather fragile way.
> >>
> >> Yeah, that's true, but I'm not clear that we have another
> >> back-patchable fix, so doing something almost-certainly-harmless to
> >> alleviate the immediate pain seems worthwhile.
> >
> > Isn't that still leaving the very related issue of waits due to hot
> > pruning open?
>
> Yes. Do you have a back-patchable solution for that?
The easiest thing I can think of is sprinkling a few
SetConfigOption('synchronous_commit', 'off', PGC_INTERNAL, PGC_S_OVERRIDE,
GUC_ACTION_LOCAL,true, ERROR);
in some strategic places. From a quick look:
* all of autovacuum
* locally in ProcessCompletedNotifies
* locally in ProcessIncomingNotify
* locally in ProcessCatchupEvent
* locally in InitPostgres
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
