2013/12/9 Andres Freund <andres@2ndquadrant.com>:
> Hi,
>
> On 2013-12-09 13:47:34 +0000, petr@petrovich.kiev.ua wrote:
>> PostgreSQL version: 9.3.2
>
>> I've installed new slave database on 6th of December. Since there was no
>> packages on apt.postgresql.org with postgresql 9.3.0 I've set up postgresql
>> 9.3.2
>
>> 2013-12-09 10:10:24 EET 172.18.10.45 main ERROR: could not access status of
>> transaction 24568845
>> 2013-12-09 10:10:24 EET 172.18.10.45 main DETAIL: Could not open file
>> "pg_multixact/members/CD8F": No such file or directory.
>
>> My next step was to upgrade to postgresql 9.3.2 on master and to do initial
>> sync from scratch.
>> It does not help. I still have the same error.
>
> Could you post, as close as possible to the next occurance of that
> error:
> * pg_controldata output from the primary
> * pg_controldata output from the standby
Sorry, I've just downgraded all the cluster to 9.3.0, and this error
disappeared.
I can provide output right now, if it make any sence.
But the same query with the same id *always* gave the same error not
depending on replication state.
One more thing: I had a look on previous fay logs and find following:
2013-12-08 21:17:15 EET LOG: could not truncate directory
"pg_multixact/members": apparent wraparound
2013-12-08 21:22:20 EET LOG: could not truncate directory
"pg_multixact/members": apparent wraparound
2013-12-08 21:27:26 EET LOG: could not truncate directory
"pg_multixact/members": apparent wraparound
AT some point at time there was no "apparent wraparound" message
anymore, but just "Could not open file"
> * SELECT datfrozenxid, datminmxid FROM pg_database;
datfrozenxid | datminmxid
--------------+------------
710 | 1
710 | 1
710 | 1
710 | 1
>
> Do you frequently VACUUM FREEZE on the primary? Have you modified any of
> the vacuum_freeze_* parameters?
I never run VACUUM FREEZE manually
The only changed vacuum_* parameter is
vacuum_cost_delay = 10
>
>> I think it may be tied to this commit:
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=215ac4ad6589e0f6a31cc4cd867aedba3cd42924
>
> Only incidentally I think - we didn't properly maintain it during
> recovery before at all.
>
