Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi6X1-0008D5-VT for pgsql-docs@arkaria.postgresql.org; Fri, 02 Oct 2015 20:02:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1Zi6X0-0003DF-8k for pgsql-docs@arkaria.postgresql.org; Fri, 02 Oct 2015 20:02:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1Zi6Wz-0003CM-9M; Fri, 02 Oct 2015 20:02:13 +0000 Received: from mail-la0-x22b.google.com ([2a00:1450:4010:c03::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Zi6Ww-0006yf-PM; Fri, 02 Oct 2015 20:02:12 +0000 Received: by lalw10 with SMTP id w10so558747lal.3; Fri, 02 Oct 2015 13:02:08 -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=tVQ/NUDNY/NKbIvOzjp10DVzafrUAJ/JI23Lg7qOtOQ=; b=XRKeKwAI1MqjJOIl51foggLgFpeVgOBH9grMUQGXfwr5xotibwZPpaDHhW1RofmwuN DNHWZpXX6B7kaJM+CbMdotBb7FU9Xb+Ra5kbuK2oIEHE7IZFlG7wQDvlLD4HZzsfm+YJ Bs2Tu1j6BJD9FNiNmRPfqK7T4bjawOTTJH5UQHjqoLWE1qviNqoBS3NpfPW05LUnjtFm GxnzfawTlvqdJStslWQM4cXjn0uuAosW6NrxCj0yo7irJmPXjsQIkJA9sqH8+hAkmy3B 4SH97z3d1tQfJ4xnv9PzYoOKzDndCvdcspQfqWhehBtLnqqkbPn1W8vE/t4xDsSQovY0 fx6g== MIME-Version: 1.0 X-Received: by 10.112.147.39 with SMTP id th7mr6171858lbb.82.1443816128623; Fri, 02 Oct 2015 13:02:08 -0700 (PDT) Received: by 10.112.44.101 with HTTP; Fri, 2 Oct 2015 13:02:08 -0700 (PDT) In-Reply-To: <20151002185941.GE2573@alvherre.pgsql> References: <20150930224806.GR2573@alvherre.pgsql> <20151001181240.GT2573@alvherre.pgsql> <20151002145839.GZ2573@alvherre.pgsql> <20151002185941.GE2573@alvherre.pgsql> Date: Fri, 2 Oct 2015 16:02:08 -0400 Message-ID: Subject: Re: max_worker_processes on the standby From: Robert Haas To: Alvaro Herrera Cc: Fujii Masao , 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 Fri, Oct 2, 2015 at 2:59 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> The standby can have the feature enabled even though the master has it >> disabled? That seems like it can only lead to heartache. > > Can you elaborate? Sort of. Our rule up until now has always been that the standby is an exact copy of the master. I suspect deviating from that behavior will introduce bugs. I suspect having the standby make data changes that aren't WAL-logged will introduce bugs; not to be unkind, but that certainly seems like a lesson to take from what happened with multixacts. I haven't looked at this code well enough to guess specifically what will go wrong. But consider people turning the feature on and off repeatedly on the master, and separately on the standby, combined with crashes on the standby that restart replay from earlier points (possibly with settings that have changed in the meantime). Are we really sure that we're never going to end up with the wrong files, or inconsistent ones, on the standby? I have a really hard time believing that's going to work out. -- 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