Re: Recovery inconsistencies, standby much larger than primary

From: Greg Stark <stark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recovery inconsistencies, standby much larger than primary
Date: 2014-02-13 09:59:48
Message-ID: CAM-w4HMcXAM-x1SRgOc1J2vz=hoP84YvO2xs=WGTw2vjpGzA7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I think what you're arguing is that we should see WAL records filling the
> rest of segment 1 before we see any references to segment 2, but if that's
> the case then how did we get into the situation you reported? Or is it
> just that it was a broken base backup to start with?

The scenario I could come up with that didn't require a broken base backup
was that there was an earlier truncate or vacuum. So the sequence is high
offset reference, truncate, growth, crash. All possibly on a single
database.

It's possible we're better off not assuming we've thought of all possible
ways this can happen though.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Beck 2014-02-13 10:01:00 New hook after raw parsing, before analyze
Previous Message Amit Langote 2014-02-13 09:47:35 Re: how set GUC_check_errhint_string in call_string_check_hook()