Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Zs6xR-0003Zp-4Z for pgsql-docs@arkaria.postgresql.org; Fri, 30 Oct 2015 10:30:53 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1Zs6xQ-0006Vt-I7 for pgsql-docs@arkaria.postgresql.org; Fri, 30 Oct 2015 10:30:52 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1Zs6x4-0005lP-Ks; Fri, 30 Oct 2015 10:30:30 +0000 Received: from mail-lb0-x235.google.com ([2a00:1450:4010:c04::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Zs6wt-0004Zj-QF; Fri, 30 Oct 2015 10:30:29 +0000 Received: by lbbec13 with SMTP id ec13so47909839lbb.0; Fri, 30 Oct 2015 03:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9IyxuaumdA3+SNJQYQxBkk8oQbhRDeP5oO9T7FJGsBs=; b=jCoa5gVz1qL/9/zOY3P6imjG4bO+Pjd1X7yWzqURMVhcGaremi/UfxVc8KgG8Gu/ZT kREPptZUA3u5FVJ9Bj1uP2quUaqJf+ipZAr3OWbOas4AWgYAv7yyxnUAjrv9GeHkYZmq VMWRuJxrpvAxyu9Prb4WVBKnc9QYhZMsOkjrrOAr33onzk5SFqN/5gJBxoq4p+SsGGKJ 4ycQOPUuG453Sr+UAEiezb6bzfO1fjCY6coko+fKZNk8o3khXrVS2hqSbBThlADjAyd8 9oZpf51hiJ2WwDyGbOXjy29D5MLt9J/P0tphqGJ2TUJ/ZrHoig4Lww2mzUJwowmQLOW+ 7O6A== MIME-Version: 1.0 X-Received: by 10.112.77.10 with SMTP id o10mr3628994lbw.28.1446201017854; Fri, 30 Oct 2015 03:30:17 -0700 (PDT) Received: by 10.112.44.101 with HTTP; Fri, 30 Oct 2015 03:30:17 -0700 (PDT) In-Reply-To: References: <20151001181240.GT2573@alvherre.pgsql> <20151002145839.GZ2573@alvherre.pgsql> <20151002185941.GE2573@alvherre.pgsql> <5622BF9D.2010409@2ndquadrant.com> <20151020190522.GT3391@alvherre.pgsql> <20151027180759.GG240637@alvherre.pgsql> Date: Fri, 30 Oct 2015 11:30:17 +0100 Message-ID: Subject: Re: [HACKERS] max_worker_processes on the standby From: Robert Haas To: Fujii Masao Cc: Alvaro Herrera , Petr Jelinek , oonishitk@nttdata.co.jp, pgsql-docs , PostgreSQL-development Content-Type: text/plain; charset=UTF-8 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org On Thu, Oct 29, 2015 at 5:41 PM, Fujii Masao wrote: > I found another strange behavior on track_commit_timestamp. > Here are the steps to reproduce it. > > 1. Start the master and standby servers with track_commit_timestamp enabled. > Since committs is activated in standby, pg_last_committed_xact() can > successfully return the timestamp of last transaction as expected. > > 2. Disable track_commit_timestamp in the master and restart the master server. > The parameter-change WAL record is streamed to the standby and committs > is deactivated. pg_last_committed_xact() causes an ERROR in the standby. > > 3. Run checkpoint in the master. > > 4. Run restartpoint in the standby after the checkpoint WAL record generated > in #3 is replicated to the standby. > > 5. Restart the standby server. > Committs is activated in the standby because track_commit_timestamp is > enabled. This seems wrong already at this point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs