Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M276572=pgsql-hackers-arkari@postgresql.org>)
 id 1ZB4XF-0004NX-27
 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2015 17:13:57 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.84) (envelope-from
 <pgsql-hackers-owner+M276572=pgsql-hackers-arkari@postgresql.org>)
 id 1ZB4XE-0007zc-EZ
 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2015 17:13:56 +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 <kleptog@svana.org>) id 1ZB4XC-0007zT-2q
 for pgsql-hackers@postgresql.org; Fri, 03 Jul 2015 17:13:54 +0000
Received: from bilbys.org ([2400:c400::113:212:99:188] helo=svana.org)
 by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.84) (envelope-from <kleptog@svana.org>) id 1ZB4X8-0005Rw-6R
 for pgsql-hackers@postgresql.org; Fri, 03 Jul 2015 17:13:52 +0000
Received: from kleptog by svana.org with local (Exim 4.72)
 (envelope-from <kleptog@svana.org>)
 id 1ZB4Xi-0000u8-GD; Sat, 04 Jul 2015 03:14:28 +1000
Date: Fri, 3 Jul 2015 19:14:26 +0200
From: Martijn van Oosterhout <kleptog@svana.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@gmail.com>, Andres Freund <andres@anarazel.de>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Message-ID: <20150703171426.GA2841@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
References: <20150702220524.GA9392@svana.org>
 <20150702222102.GG30708@awork2.anarazel.de>
 <20150703052048.GA20285@svana.org>
 <CAHGQGwEXta1tMF6o-FcDcjMgCF=jnZLj3v3EoePvsEN4aexJnA@mail.gmail.com>
 <20150703060137.GB20285@svana.org>
 <CAHGQGwFtOMv5h8eKX6zf+9_0UxpcTsyH9xAnyv6KdGH4BonLiw@mail.gmail.com>
 <28320.1435935120@sss.pgh.pa.us>
 <CAHGQGwGzxAyKLUm+z2n43-ee6u976jLmQAz=pPBVzSueD3CAig@mail.gmail.com>
 <10146.1435942436@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6"
Content-Disposition: inline
In-Reply-To: <10146.1435942436@sss.pgh.pa.us>
X-PGP-Key-ID: Length=4096; ID=0x4BE62D44
X-PGP-Key-Fingerprint: AF6F C0D6 3B8A AF7D 942B  D2BC 4BED FBE7 4BE6 2D44
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kleptog@svana.org
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on calyx
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_RELAYS
 autolearn=ham version=3.3.1
Subject: Re: WAL logging problem in 9.4.3?
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000)
X-SA-Exim-Scanned: Yes (on svana.org)
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 03, 2015 at 12:53:56PM -0400, Tom Lane wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
> > Okay, so probably we need to change WAL replay of TRUNCATE so that
> > the index file is truncated to one containing only meta page instead of
> > empty one. That is, the WAL replay of TRUNCATE would need to call
> > index_build() after smgrtruncate() maybe.
>=20
> That seems completely unworkable.  For one thing, index_build would expect
> to be able to do catalog lookups, but we can't assume that the catalogs
> are in a good state yet.
>=20
> I think the responsibility has to be on the WAL-writing end to emit WAL
> instructions that lead to a correct on-disk state.  Putting complex
> behavior into the reading side is fundamentally misguided.

Am I missing something. ISTM that if the truncate record was simply not
logged at all everything would work fine. The whole point is that the
table was created in this transaction and so if it exists the table on
disk must be the correct representation.

The broken index is just one symptom. The heap also shouldn't be
truncated at all. If you insert a row before commit then after replay
the tuple should be there still.

Have a nice day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
   -- Arthur Schopenhauer

--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIVAwUBVZbC8Uvt++dL5i1EAQgzng//bx4slYWqMrPXC/LmzgnBztSqruFJxIjX
4bEoKHIcB6mYBy9r2jiJGVr+gIEoTwhlA9DTux+tf0D8HnGfMwLezTR49rpnS5k/
zyRMUahQ63TuGmzGWG8cnRCtWSvJ4E8gecYlHUv/pRUT6annKGSF25+Lqq+nfDZq
p122gNqApKW4m3MCvMUAVjDKhH4OYpaJfdNkmNrFqqThRt3/efc29FVowA+5z3uX
NxdueQCK1CtcCJyhRXXkLFC3CUnkgsINMpW4/kSgTnUzT3LBFyOY+lnOovjfXH9h
9yIssnEyqDP1s+J3MxCKHT9Tu1DrVoF2wCcnveTkN+UglDb33aHbwe/YF7ZyyKep
vTb3KZFHglL+fHSaf0KlZ17Se3npkpmKcUatD9DBILEvQJzypfIhynzsxx9lYcVo
P+9F8dATlNF5NFtD/uL+p8rM82iEW4cjn6JzndGgMmLMI8W4zxSCdNDkwlT/5BBw
bCIKFy1ijx8oMxGsQKwsw/eED+Qo5GNRPsMGDKnpvuLQ4E5zb8TlrErpWWMMcGWq
ZW5sjwr0pTHnhR5R3T7hF3VvHOfbNAtkmL8fDHVylSwX8uk8a3SFU6j1q1UGSWoq
zD7Qo2dwQWrd2O7n0W9jYApkIx2syrbpecoKKPO6ROzBw9BV6Mo43cbT3KjBfixW
XqEDTILwdgc=
=h9LO
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--