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

From Andres Freund
Subject Re: Recovery inconsistencies, standby much larger than primary
Date
Msg-id 20140131150820.GG13199@alap3.anarazel.de
Whole thread Raw
In response to Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
Responses Re: Recovery inconsistencies, standby much larger than primary  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On 2014-01-31 14:59:21 +0000, Greg Stark wrote:
> On Fri, Jan 31, 2014 at 2:39 PM, Greg Stark <stark@mit.edu> wrote:
> > [cur:EA1/637140, xid:1418089147, rmid:11(Btree), len/tot_len:18/6194,
> > info:8, prev:EA1/635290] bkpblock[1]: s/d/r:1663/16385/1261982
> > blk:3634978 hole_off/len:1240/2072
> > [cur:EA1/638988, xid:1418089147, rmid:11(Btree), len/tot_len:18/5894,
> > info:8, prev:EA1/637140] insert_leaf: s/d/r:1663/16385/1364767 tid
> > 2746914/219
> 
> Actually wait, the immediate previous record is indeed on the right
> filenode. Is the LSN printed in xlogdump the LSN that would be in the
> pd_lsn or is the pd_lsn going to be from the following record?

It points to the end of the record (i.e. the beginning of the next). It
needs to, because otherwise XLogFlush()es on the pd_lsn wouldn't flush
enough.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Prohibit row-security + inheritance in 9.4?
Next
From: "MauMau"
Date:
Subject: Re: [bug fix] psql \copy doesn't end if backend is killed