Re: Recovery inconsistencies, standby much larger than primary - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Recovery inconsistencies, standby much larger than primary
Date
Msg-id CAM-w4HMcXAM-x1SRgOc1J2vz=hoP84YvO2xs=WGTw2vjpGzA7A@mail.gmail.com
Whole thread Raw
In response to Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Recovery inconsistencies, standby much larger than primary  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
<p dir="ltr"><br /><p dir="ltr">> I think what you're arguing is that we should see WAL records filling the<br />
>rest of segment 1 before we see any references to segment 2, but if that's<br /> > the case then how did we get
intothe situation you reported?  Or is it<br /> > just that it was a broken base backup to start with?<p
dir="ltr">Thescenario I could come up with that didn't require a broken base backup was that there was an earlier
truncateor vacuum. So the sequence is high offset reference, truncate, growth, crash. All possibly on a single
database.<pdir="ltr">It's possible we're better off not assuming we've thought of all possible ways this can happen
though.

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: how set GUC_check_errhint_string in call_string_check_hook()
Next
From: David Beck
Date:
Subject: New hook after raw parsing, before analyze