Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby
Date
Msg-id 20140606013943.GT5146@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby  (Serge Negodyuck <petr@petrovich.kiev.ua>)
Responses Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-bugs
Serge Negodyuck wrote:

> 2014-06-02 08:20:55 EEST 172.18.10.4 db PANIC: could not access status of
> transaction 2080547
> 2014-06-02 08:20:55 EEST 172.18.10.4 db DETAIL: Could not open file
> "pg_multixact/members/14078": No such file or directory.
> 2014-06-02 08:20:55 EEST 172.18.10.4 db CONTEXT: SQL statement "  UPDATE
> ....."

So as it turns out, this was caused because the arithmetic to handle the
wraparound case neglected to handle multixacts with more members than
the number that fit in the last page(s) of the last segment, leading to
a number of pages in the 14078 segment (or whatever the last segment is
for a given BLCKSZ) to fail to be initialized.  This patch is a rework
of that arithmetic, although it seems little bit too obscure.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process
Next
From: ua2fgb@gmail.com
Date:
Subject: BUG #10528: MAC OS X was renamed