Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YuRuW-0007Cf-Dq for pgsql-hackers@arkaria.postgresql.org; Mon, 18 May 2015 20:45:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YuRuV-0007r4-Ur for pgsql-hackers@arkaria.postgresql.org; Mon, 18 May 2015 20:45:15 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YuRuU-0007qW-Os for pgsql-hackers@postgresql.org; Mon, 18 May 2015 20:45:14 +0000 Received: from mail-qk0-f170.google.com ([209.85.220.170]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1YuRuO-0006mQ-Lj for pgsql-hackers@postgresql.org; Mon, 18 May 2015 20:45:13 +0000 Received: by qkai132 with SMTP id i132so51265970qka.2 for ; Mon, 18 May 2015 13:45:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=P1JlwbuI4d1ZzOwMQ+2h5i5YWJLfttrzY3FJwFe5KI8=; b=P/NGBYNZkXgJZ51iuDpvSJLE4cm7LWigRUuHazoFTdD+Ntm3qKHxP82uiL72VkU//n BM60rCGFttHS+gAs0Ki4XPD3lJbQ3vEHBvhv5ZmNzcKi9zJvADYCJgeyKGCzMX7fF2Us VbG3wOnroLiQANgpjkixA94mej3UOgyMVIDuecKYprygFXBa0aI9HdCc1i/YHxDwLQLY QoZn5R4ILg2r2uW297l38UwpQmD0h31oy7vRv4BlgBmel1paFgEa8NCGzbM90vh+G8b0 dgGD9s3DbX22NRVgaRARTSoIwW3GhQaV8NrSCpJRZ3pnQB3N6CGfmFwx9O4WyLOo3wVf vrpg== X-Gm-Message-State: ALoCoQmzWALsDIe1OFU3gxd/cy4mOy9O05Kfe+zhnxbgSTeGfy4OMvrOMrBvTfXyONFi14afFn9M X-Received: by 10.140.202.211 with SMTP id x202mr11049609qha.76.1431981907324; Mon, 18 May 2015 13:45:07 -0700 (PDT) Received: from alvin.alvh.no-ip.org ([186.37.57.236]) by mx.google.com with ESMTPSA id g40sm5825qkh.18.2015.05.18.13.45.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 13:45:06 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 6CC3C879; Mon, 18 May 2015 17:45:46 -0300 (CLT) Date: Mon, 18 May 2015 17:45:46 -0300 From: Alvaro Herrera To: Simon Riggs Cc: Andres Freund , Marko Tiikkaja , hackers Subject: Re: ERROR: cannot GetMultiXactIdMembers() during recovery Message-ID: <20150518204546.GU2523@alvh.no-ip.org> References: <54EB3283.2080305@joh.to> <20150223141300.GB30784@awork2.anarazel.de> <20150515180335.GE2523@alvh.no-ip.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Simon Riggs wrote: > On 15 May 2015 at 19:03, Alvaro Herrera wrote: > > > Andres Freund wrote: > > > > > Alternatively we could make MultiXactIdIsRunning() return false < 9.3 > > > when in recovery. I think that'd end up fixing things, but it seems > > > awfully fragile to me. > > > > Hm, why fragile? It seems a pretty decent answer -- pre-9.3, it's not > > possible for a tuple to be "locked" in recovery, is it? I mean, in the > > standby you can't lock it nor update it; the only thing you can do is > > read (select), and that is not affected by whether there is a multixact > > in it. > > It can't return true and won't ever change for <9.3 so I don't see what the > objection is. Pushed. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers