Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?

<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.....