Hi,
On 2013-12-18 16:20:48 +0200, Serge Negodyuck wrote:
> You guys were right. After a week this issue occured again on almost
> all slave servers.
Not surprising.
> My question is are there any quick-and-dirty solution to disable
> pg_multixact deletion? I understand it may lead to waste of space.
Your problem isn't the deletion but that a) multixactid members wrapped
around, partially overwriting old data b) some multixacts contain too
old members (c.f. 9.3.2)
> The only way out was to perform full backup/restore, which did not
> succeed with teh same error (could not access status of transaction
> xxxxxxx)
> A very ugly hack was to copy pg_multixact/members/0000 ->
> pg_multixact/members/[ABCDF]xxx, it helped to do full backup, but not
> sure about consistency of data.
That will likely cause corruption.
I think your best bet is to hack GetMultiXactIdMembers to return -1 for
old multixacts, on the theory that those rows would have been removed by
VACUUM if they had a valid xmax.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
