Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Steve Kehlet <steve(dot)kehlet(at)gmail(dot)com>, Forums postgresql <pgsql-general(at)postgresql(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Date: 2015-05-29 14:17:17
Message-ID: 28384.1432909037@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Fri, May 29, 2015 at 11:24 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> B. We need to change find_multixact_start() to fail softly.

> Here is an experimental WIP patch that changes StartupMultiXact and
> SetMultiXactIdLimit to find the oldest multixact that exists on disk
> (by scanning the directory), and uses that if it is more recent than
> the oldestMultiXactId from shmem,

Not sure about the details of this patch, but I was planning to propose
what I think is the same thing: the way to make find_multixact_start()
fail softly is to have it find the oldest actually existing file if the
one that should be there isn't.

This would preserve the idea that we aren't trusting the multixact
tracking data to be completely right, which was the point of 78db307bb
and which evidently is still essential. It would also obviate the need
for other places to contain similar logic.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Melvin Davidson 2015-05-29 15:22:18 Re: Planner cost adjustments
Previous Message Daniel Begin 2015-05-29 13:39:00 Planner cost adjustments

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-29 14:23:24 Re: fsync-pgdata-on-recovery tries to write to more files than previously
Previous Message Joshua D. Drake 2015-05-29 13:47:02 Re: RFC: Remove contrib entirely