Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-admin-owner+archive@lists.postgresql.org>)
	id 1pjLCR-0007Ad-VS
	for pgsql-admin@arkaria.postgresql.org; Mon, 03 Apr 2023 14:30:23 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-admin-owner+archive@lists.postgresql.org>)
	id 1pjLCQ-0003r3-Pi
	for pgsql-admin@arkaria.postgresql.org; Mon, 03 Apr 2023 14:30:22 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <rui@crazybean.net>)
	id 1pjLCQ-0003qt-EM
	for pgsql-admin@lists.postgresql.org; Mon, 03 Apr 2023 14:30:22 +0000
Received: from impout006aa.msg.chrl.nc.charter.net ([47.43.20.30]
 helo=impout006.msg.chrl.nc.charter.net)
	by makus.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <rui@crazybean.net>)
	id 1pjLCN-0004ac-UL
	for pgsql-admin@lists.postgresql.org; Mon, 03 Apr 2023 14:30:21 +0000
Received: from cerberus.crazybean.net ([71.11.29.254])
	by cmsmtp with ESMTP
	id jLCLpihvuvvvvjLCMpSn4a; Mon, 03 Apr 2023 14:30:19 +0000
Authentication-Results: crazybean.net; none
X-Authority-Analysis: v=2.4 cv=a/sjSGeF c=1 sm=1 tr=0 ts=642ae2fb
 a=GkUsAQdcAzAk0MT19QAIRQ==:117 a=GkUsAQdcAzAk0MT19QAIRQ==:17
 a=xqWC_Br6kY4A:10 a=dKHAf1wccvYA:10 a=o5vz2fXQQPmGekqEYO0A:9
 a=CjuIK1q_8ugA:10 a=ZXulRonScM0A:10 a=C6dUDPiaCvL_0Sid1M0A:9
 a=R2M3Hta6vIOOr0tL:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10
Received: from smtpclient.apple (<unknown>
 [2001:470:e117:4:9d9d:3d4:d9e2:8f12])
	by cerberus.crazybean.net (OpenSMTPD) with ESMTPSA id b3924b6b
 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO);
	Mon, 3 Apr 2023 10:30:15 -0400 (EDT)
From: Rui DeSousa <rui@crazybean.net>
Message-Id: <718AEDDD-FE66-4865-A362-0A7B760B5DF1@crazybean.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FDDA342D-A7D2-4D98-8B89-74F48CDDB114"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\))
Subject: Re: A Question about FPW and WAL
Date: Mon, 3 Apr 2023 10:30:11 -0400
In-Reply-To: <942e247261151cddf5d57cf7797d6bf3c9b067a7.camel@cybertec.at>
Cc: Dawn Yu <boyyuxiao1987@gmail.com>,
 pgsql-admin@lists.postgresql.org
To: Laurenz Albe <laurenz.albe@cybertec.at>
References: 
 <CALiuKDHL-5h4DWYKiCXpQHJ8UHEG7mKj38eJVGWeT=nf604bLQ@mail.gmail.com>
 <942e247261151cddf5d57cf7797d6bf3c9b067a7.camel@cybertec.at>
X-Mailer: Apple Mail (2.3696.120.41.1.3)
X-CMAE-Envelope: 
 MS4xfNxJ9qspCjHr/BZmOOwenFv56sPQLZL1QqAkKyPtWJBqyRsUn86DKUXM/1HOF9Dm7AYWQDn5Z/DHNj3e5QzClwhiyoYPdBVF9hCWIt8G2/0GS2tWHRbd
 FakH5o0MTRj9kj2Hdp/aW0EejHlZZHuJYEgzwQkF5KwXQDFy6upuJwHguaVTOaU8CsCg9C9lAoovc/oizRziaHyy5Jdp8hYNtXGFdp0RIyHrzfDsJAmi3l+I
 9egRN6RATyQ/apcGNwMd32cQE/rM0/n+//mClELV6Z0Oj4v5Dl0IWNXbBFjTwCKj
List-Id: <pgsql-admin.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-admin@lists.postgresql.org>
List-Owner: <mailto:pgsql-admin-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-admin>
Archived-At: 
 <https://www.postgresql.org/message-id/718AEDDD-FE66-4865-A362-0A7B760B5DF1%40crazybean.net>
Precedence: bulk


--Apple-Mail=_FDDA342D-A7D2-4D98-8B89-74F48CDDB114
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Apr 3, 2023, at 5:38 AM, Laurenz Albe <laurenz.albe@cybertec.at> =
wrote:
>=20
>> By default, index full-page write is disabled. If the index is =
broken, you can
>> rebuild the index to solve it. Although the security of index data =
cannot be
>> guaranteed, this setting can greatly reduce the problem of storage =
space explosion
>> caused by wal write amplification.
>=20
> I would feel funny about a parameter like that.

I agree. To allow for indexes to become corrupt by design would be a bad =
idea. Rebuilding indexes is a not a solution as some index rebuilds =
takes hours on very large tables. Dealing with identifying corrupted =
indexes and the issues caused by them would be a nightmare to deal with =
and not very ACID compliant.=

--Apple-Mail=_FDDA342D-A7D2-4D98-8B89-74F48CDDB114
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Apr 3, 2023, at 5:38 AM, Laurenz Albe &lt;<a =
href=3D"mailto:laurenz.albe@cybertec.at" =
class=3D"">laurenz.albe@cybertec.at</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; =
font-size: 14px; font-style: normal; font-variant-caps: normal; =
font-weight: 400; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">By =
default, index full-page write is disabled. If the index is broken, you =
can<br class=3D"">rebuild the index to solve it. Although the security =
of index data cannot be<br class=3D"">guaranteed, this setting can =
greatly reduce the problem of storage space explosion<br class=3D"">caused=
 by wal write amplification.<br class=3D""></blockquote><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
14px; font-style: normal; font-variant-caps: normal; font-weight: 400; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
14px; font-style: normal; font-variant-caps: normal; font-weight: 400; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">I would feel funny about a =
parameter like that.</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""></div></div></blockquote></div><br =
class=3D""><div class=3D"">I agree. To allow for indexes to become =
corrupt by design would be a bad idea. Rebuilding indexes is a not a =
solution as some index rebuilds takes hours on very large tables. =
Dealing with identifying corrupted indexes and the issues caused by them =
would be a nightmare to deal with and not very ACID =
compliant.</div></body></html>=

--Apple-Mail=_FDDA342D-A7D2-4D98-8B89-74F48CDDB114--