Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Date
Msg-id 20150605160014.GA24997@alap3.anarazel.de
Whole thread Raw
In response to Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2015-06-05 11:43:45 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Fri, Jun 5, 2015 at 2:20 AM, Noah Misch <noah@leadboat.com> wrote:
> >> I read through this version and found nothing to change.  I encourage other
> >> hackers to study the patch, though.  The surrounding code is challenging.
>
> > Andres tested this and discovered that my changes to
> > find_multixact_start() were far more creative than intended.
> > Committed and back-patched with a trivial fix for that stupidity and a
> > novel-length explanation of the changes.
>
> So where are we on this?  Are we ready to schedule a new set of
> back-branch releases?  If not, what issues remain to be looked at?

We're currently still doing bad things while the database is in an
inconsistent state (i.e. read from SLRUs and truncate based on the
results of that). It's quite easy to reproduce base backup startup
failures.

On the other hand, that's not new. And the fix requires, afaics, a new
type of WAL record (issued very infrequently). I'll post a first version
of the patch, rebased ontop of Robert's commit, tonight or tomorrow. I
guess we can then decide what we'd like to do.


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [CORE] Restore-reliability mode
Next
From: Jim Nasby
Date:
Subject: Re: [CORE] Restore-reliability mode