Breakage with VACUUM ANALYSE + partitions

Hi,

I've not determined what's causing the following issue, but this is
the simplest reproducible test case I've managed to create so far in
9.6 latest git master:

postgresql.conf:
  shared_buffers =3D 256MB

createdb pgbench
pgbench -i -s 80 pgbench

psql pgbench
  \pset pager off
  CREATE TABLE pgbench_accounts_1 (CHECK (bid % 2 =3D 0)) INHERITS
(pgbench_accounts);
  CREATE TABLE pgbench_accounts_2 (CHECK (bid % 2 =3D 1)) INHERITS
(pgbench_accounts);
  WITH del AS (DELETE FROM pgbench_accounts WHERE bid % 2 =3D 0
RETURNING *) INSERT INTO pgbench_accounts_1 SELECT * FROM del;
  WITH del AS (DELETE FROM pgbench_accounts WHERE bid % 2 =3D 1
RETURNING *) INSERT INTO pgbench_accounts_2 SELECT * FROM del;
  VACUUM ANALYSE;
  EXPLAIN ANALYSE SELECT count(*) FROM pgbench_accounts;

This last statement produces:
  ERROR:  could not read block 0 in file "base/35160/35173": read only
0 of 8192 bytes

Looking at the file, I get:

  File: =E2=80=9835173=E2=80=99
  Size: 0             Blocks: 0          IO Block: 4096   regular empty fil=
e
Device: 801h/2049d    Inode: 4504115     Links: 1
Access: (0600/-rw-------)  Uid: (1000001/    thom)   Gid: (1000001/    thom=
)
Access: 2016-03-20 19:37:50.433485085 +0000
Modify: 2016-03-20 19:39:49.422959222 +0000
Change: 2016-03-20 19:39:49.422959222 +0000
 Birth: -

This is the same file info I get if I just to a regular VACUUM
instead, but that doesn't result in the error.  And if I follow that
up with a VACUUM ANALYSE, the error still doesn't occur.

The base directory also shows this listing for files name after the
affected filenode:

-rw------- 1 thom thom     0 Mar 20 19:39 35173
-rw------- 1 thom thom     0 Mar 20 19:39 35173.1
-rw------- 1 thom thom 16384 Mar 20 19:39 35173_fsm
-rw------- 1 thom thom     0 Mar 20 19:39 35173_vm

After I see the error, I get the same error again if I then try to run
plain VACUUM.

The oid 35173 shown in this error message references the parent
pgbench_accounts table.

If I reduce the scale factor to 50, or increase shared_buffers to
512MB, there's no error.  If, instead of VACUUM ANALYSE, I just use
VACUUM, or just ANALYSE,  the error doesn't happen.

System details:
OS: Linux Mint Debian Edition (Wheezy 7.0)
Linux Kernel: 3.11.8
RAM: 16GB
Filesystem: ext4 (rw,noatime,discard,errors=3Dremount-ro,data=3Dordered)

Regard

Thom