Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem? - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?
Date
Msg-id CAM-w4HN7jU1qvUywRsiHGfNNNGYBsaRUoNuF1bm3sLD_ewfErg@mail.gmail.com
Whole thread Raw
In response to Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?
List pgsql-hackers
<p dir="ltr"><br /> On 28 Feb 2014 06:19, "Andres Freund" <<a
href="mailto:andres@2ndquadrant.com">andres@2ndquadrant.com</a>>wrote:<br /> ><br /> > On 2014-02-27 23:41:08
+0000,Greg Stark wrote:<br /> > > Though I notice something I can't understand here.<br /> > ><br /> >
>After activating the new clone subsequent attempts to select rows from<br /> > > the page bump the LSN,
presumablydue to touching hint bits (since the<br /> > > prune xid hasn't changed). But the checksum hasn't
changedeven after<br /> > > running CHECKPOINT.<br /> ><br /> > Are you running with
full_page_writes=off?<pdir="ltr">No<br /><p dir="ltr">> Only delete and update do a PageSetPrunable(), so prune_xid
notbeing<br /> > changed doesn't say much...<br /> ><br /> > > How is it possible for the LSN to get
updatedwithout changing the checksum?<br /> ><br /> > Generally the LSN is computed when writing, not when a
bufferis<br /> > modified, so that's not particularly surprising. It'd be interesting to<br /> > see what the
recordsare that end on those LSNs.<p dir="ltr">The checksum you mean? But that's why I ran checkpoint. <br /><p
dir="ltr">>It'd probably nice to add the capability to dump records that end in a<br /> > particular location to
pg_xlogdump...<pdir="ltr">I have this crazy idea about combining xlogdump and pg_receivexlog to archive all xlog to a
postgresdatabase for querying..... 

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Fwd: patch: make_timestamp function
Next
From: Andres Freund
Date:
Subject: Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?