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

2014-06-10 16:48 GMT+03:00 Alvaro Herrera <alvherre@2ndquadrant.com>:
> Serge Negodyuck wrote:
>> 2014-06-09 22:49 GMT+03:00 Alvaro Herrera <alvherre@2ndquadrant.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)