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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(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: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Date: 2015-06-08 17:06:31
Message-ID: 20150608170631.GI133018@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Andres Freund wrote:

> A first version to address this problem can be found appended to this
> email.
>
> Basically it does:
> * Whenever more than MULTIXACT_MEMBER_SAFE_THRESHOLD are used, signal
> autovacuum once per members segment
> * For both members and offsets, once hitting the hard limits, signal
> autovacuum everytime. Otherwise we loose the information when
> restarting the database, or when autovac is killed. I ran into this a
> bunch of times while testing.

I might be misreading the code, but PMSIGNAL_START_AUTOVAC_LAUNCHER only
causes things to happen (i.e. a new worker to be started) when
autovacuum is disabled. If autovacuum is enabled, postmaster receives
the signal and doesn't do anything about it, because the launcher is
already running. Of course, regularly scheduled autovac workers will
eventually start running, but perhaps this is not good enough.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andres Freund 2015-06-08 17:11:01 Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Previous Message cchee-ob 2015-06-08 17:04:21 Re: BDR - Failure of Primary Server - How to recover?

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2015-06-08 17:07:56 Re: [CORE] Restore-reliability mode
Previous Message Bruce Momjian 2015-06-08 17:03:45 Re: [CORE] Restore-reliability mode