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-w4HP8fHERDtFwsqTPpaS=JOf6LkEWrp7E1zZN7xZ6g3_DTA@mail.gmail.com
Whole thread Raw
In response to Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?  (Greg Stark <stark@mit.edu>)
Responses Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Though I notice something I can't understand here.

After activating the new clone subsequent attempts to select rows from
the page bump the LSN, presumably due to touching hint bits (since the
prune xid hasn't changed). But the checksum hasn't changed even after
running CHECKPOINT.

How is it possible for the LSN to get updated without changing the checksum?

postgres=# select (page_header(get_raw_page('users',13065))).* ;    lsn     | checksum | flags | lower | upper |
special| pagesize |
 
version | prune_xid
-------------+----------+-------+-------+-------+---------+----------+---------+-----------FD/330EC998 |   -25547 |
1|   152 |  2576 |    8192 |     8192 |     4 |   5638282
 
(1 row)

postgres=# select (page_header(get_raw_page('users',13065))).* ;    lsn     | checksum | flags | lower | upper |
special| pagesize |
 
version | prune_xid
-------------+----------+-------+-------+-------+---------+----------+---------+-----------FD/33140160 |   -25547 |
1|   152 |  2576 |    8192 |     8192 |     4 |   5638282
 
(1 row)

postgres=# select (page_header(get_raw_page('users',13065))).* ;    lsn     | checksum | flags | lower | upper |
special| pagesize |
 
version | prune_xid
-------------+----------+-------+-------+-------+---------+----------+---------+-----------FD/350016E8 |   -25547 |
1|   152 |  2576 |    8192 |     8192 |     4 |   5638282
 
(1 row)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: UNION ALL on partitioned tables won't use indices.
Next
From: "Wang, Jing"
Date:
Subject: pg_dump reporing version of server & pg_dump as comments in the output