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-w4HOvoeu_v_nhmF+mqNH5nA7riQ0o53+6Qq+K=OL0Anumtg@mail.gmail.com
Whole thread Raw
In response to Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Thu, Feb 27, 2014 at 2:34 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Greg, Peter, if you could update your standbys to the current HEAD of
> REL9_3_STABLE for the affected apps and verify the problem no longer
> shows up in a reasonable timeframe, it would be great.  (I'm assuming
> you saw this happen repeatedly.)

Actually I can do better. I restored the same base backup and applied
the same period of logs and can confirm that the rows in question now
appear normally:

=# select * from (select
(heap_page_items(get_raw_page('users',13065))).*) as x where lp
in(2,3,4,7);
lp | lp_off | lp_flags | lp_len | t_xmin  | t_xmax  | t_field3 |
t_ctid   | t_infomask2 | t_infomask | t_hoff |
----+--------+----------+--------+---------+---------+----------+-----------+-------------+------------+--------+--- 2
|  3424 |        1 |    232 | 5943845 |  728896 |        0 |
 
(13065,3) |       16416 |       4419 |     32 | 3 |   3152 |        1 |    272 | 5943849 | 5943879 |        0 |
(13065,4) |       49184 |       9475 |     32 | 4 |   2864 |        1 |    287 | 5943879 | 5943880 |        0 |
(13065,7) |       49184 |       9475 |     32 | 7 |   2576 |        1 |    287 | 5943880 |       0 |        0 |
(13065,7) |       32800 |      10499 |     32 |



-- 
greg



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Backup throttling
Next
From: Tom Lane
Date:
Subject: Re: UNION ALL on partitioned tables won't use indices.