Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJScZ-0007RR-A6 for pgsql-bugs@arkaria.postgresql.org; Fri, 09 Jun 2017 22:43:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dJScY-0004P3-T3 for pgsql-bugs@arkaria.postgresql.org; Fri, 09 Jun 2017 22:43:10 +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_2) (envelope-from ) id 1dJScY-0004MW-00; Fri, 09 Jun 2017 22:43:10 +0000 Received: from mail-yw0-x229.google.com ([2607:f8b0:4002:c05::229]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dJScR-0003qJ-0G; Fri, 09 Jun 2017 22:43:09 +0000 Received: by mail-yw0-x229.google.com with SMTP id v7so7815205ywc.2; Fri, 09 Jun 2017 15:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NI0Il8h61Wu9WK4eRHU+k/yH7LaV9b/XfvwXuvSH6T4=; b=qfA2MVkVpkt3wfA/xisxsu888sHldvKC/JmOik6PWUsvENqArOp2vSktHNDPuB9jA6 yBHq2+Uk4iYg4XN0Nch+NN/dmqkS9M4GA2H/qugkJLQxoYGprLN8vRXwK2EYPIL/gYkQ 0Tt/F4Bnl/oOhS6e7MwKW9sOxbLd7dDy5vHzWGCw3pN5NCo+dVwp/yyv+G416AFCeLBu cO+tNr40q+L9m5sX4pCzug6UfzNYlNlaHMzsA+YsZZXhz1hkGik9Elnnv8FaQBBvD8au xBitSsI0m854E0NY9JvOctghpzREW08HKoTlrsnxbmw+ojANXCkvZsJ447o4WicwqLSs g5tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NI0Il8h61Wu9WK4eRHU+k/yH7LaV9b/XfvwXuvSH6T4=; b=eKFvwrOmwvQsXC1BCyj0zggZFpsQau3DoTCcfN+x5mnqVD7TkEHanp93LlAvOLIVbd IGRP0rGxb4Jg02KwLmqSnxGBhYMrWQcXEXs8wQXArFCVMKoAbbb4so8mMoOqY5tQ6gvT eb6mJ5EnCBbMbACVhEBkYGwGAYnCKYx64aRyH+OpEw0fvm+pgQ68cdBdvKG57Anlmqtg XExu/chGOVnVnAJWNOyVf0hBRGGQ6urnu2aHf7PRd0Xby3KDS6Nfx38SUOLfCxvMYe9y j8n3Mn5UF95zb2qrnB8zDTbB5lzbdEF02j6MvzK/6nzYQew+HmYQljlFIZ/s3GOGQJuF iQTA== X-Gm-Message-State: AODbwcBkpWuNaJeodloIfzZpBOIY4dfCFmCAVO44YIc/eH2F52PLmAUF YIfJS+z6N71fJx2vZWfHw1xnAwA3sA== X-Received: by 10.129.131.193 with SMTP id t184mr16118598ywf.317.1497048180513; Fri, 09 Jun 2017 15:43:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.77 with HTTP; Fri, 9 Jun 2017 15:43:00 -0700 (PDT) In-Reply-To: References: From: Michael Paquier Date: Sat, 10 Jun 2017 07:43:00 +0900 Message-ID: Subject: Re: Invalid WAL segment size. Allowed values are 1,2,4,8,16,32,64 To: Cocco Gianfranco Cc: "pgsql-performance@postgresql.org" , "pgsql-bugs@postgresql.org" , DBA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org On Fri, Jun 9, 2017 at 10:55 PM, Cocco Gianfranco wrote: > Is there a way to fix =E2=80=9Cwal_segsize=E2=80=9D to about 1 Gb in 9.2.= version, and =E2=80=9Crebuild=E2=80=9D postgreSQL server? As long as you are able to compile your own version of Postgres and your distribution does not allow that, there is nothing preventing you to do so. > The goal is to drastically reduce the number of WALs. > Upgrading to 9.5, is the only way to fix this issue? Note that a server initialized with a segment size of X won't work with a binary compiled with a size of Y. But you can always take a logical dump of the server before the upgrade, and reload it in the version of the server with a larger segment size. The cost here is more downtime. --=20 Michael --=20 Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs