Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby

From: Serge Negodyuck <petr(at)petrovich(dot)kiev(dot)ua>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby
Date: 2014-06-10 14:06:49
Message-ID: CABKyZDGuxd9c8N7Ff=9sF-Lj0AvucGOfE8YPO3YrOhV=XEpOdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

2014-06-10 16:48 GMT+03:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
> Serge Negodyuck wrote:
>> 2014-06-09 22:49 GMT+03:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
>
>> > > An ugly hack "cp pg_multixact/members/14077 pg_multixact/members/14078"
>> > > helped me to start master server in replica.
>> > >
>> > > Then, did pg_basebackup to slave database. It does not help
>> > > 2014-06-02 09:58:49 EEST 172.18.10.17 db2 DETAIL: Could not open file
>> > > "pg_multixact/members/1112D": No such file or directory.
>> > > 2014-06-02 09:58:49 EEST 172.18.10.18 db2 DETAIL: Could not open file
>> > > "pg_multixact/members/11130": No such file or directory.
>> > > 2014-06-02 09:58:51 EEST 172.18.10.34 db2 DETAIL: Could not open file
>> > > "pg_multixact/members/11145": No such file or directory.
>> > > 2014-06-02 09:58:51 EEST 172.18.10.38 db2 DETAIL: Could not open file
>> > > "pg_multixact/members/13F76": No such file or directory
>> >
>> > This is strange also; if the files are present in master, how come they
>> > weren't copied to the replica? I think we need more info about this
>> > problem.
>> I've thoroughly looked through the logs once again and I have not
>> found anything interesting.
>> I just know there were very few pg_multixact/members files starting
>> from 0000. It was on both slave servers. So I've observed this issue
>> two times.
>
> But it was OK on master, right? It had the full set of files and no
> file got remove improperly? (minus 14078, which wasn't created on time,
> of course)

Yes,all files were persent on master (except for corrupted file 14078,
which was copied from the 14077, it was the fastest solution to start
master server)

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jeff Janes 2014-06-10 16:02:35 Re: Many processes blocked at ProcArrayLock!
Previous Message Alvaro Herrera 2014-06-10 13:48:42 Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-06-10 14:18:41 Re: "cancelling statement due to user request error" occurs but the transaction has committed.
Previous Message Robert Haas 2014-06-10 14:02:34 Re: "cancelling statement due to user request error" occurs but the transaction has committed.