On Fri, Jul 03, 2015 at 02:34:44PM +0900, Fujii Masao wrote: > > Hmm, for me it is 100% reproducable. Are you familiar with Docker? I > > can probably construct a Dockerfile that reproduces it pretty reliably. > > I could reproduce the problem in the master branch by doing > the following steps.
Thank you, I wasn't sure if you could kill the server fast enough without containers, but it looks like immediate mode is enough. > 1. start the PostgreSQL server with wal_level = minimal > 2. execute the following SQL statements > begin; > create table test(id serial primary key); > truncate table test; > commit; > 3. shutdown the server with immediate mode > 4. restart the server (crash recovery occurs) > 5. execute the following SQL statement > select * from test; > > The optimization of TRUNCATE opereation that we can use when > CREATE TABLE and TRUNCATE are executed in the same transaction block > seems to cause the problem. In this case, only index file truncation is > logged, and index creation in btbuild() is not logged because wal_level > is minimal. Then at the subsequent crash recovery, index file is truncated > to 0 byte... Very simple fix is to log an index creation in that case, > but not sure if that's ok to do.. Looks plausible to me. For reference I attach a small tarball for reproduction with docker. 1. Unpack tarball into empty dir (it has three small files) 2. docker build -t test . 3. docker run -v /tmp/pgtest:/data test 4. docker run -v /tmp/pgtest:/data test Data dir is in /tmp/pgtest Have a nice day, -- Martijn van Oosterhout <klep...@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
postgresql-test.tgz
Description: GNU Unix tar archive
signature.asc
Description: Digital signature
