Sorry, I should have included the index definition, its a normal btree index on a bigint column:
CREATE INDEX user_pictures_picture_dhash_idx ON user_pictures USING btree (picture_dhash); And the table itself: CREATE TABLE user_pictures (picture_dhash bigint) (and ~10 other columns not relevant for this I think) /Victor On Thu, Dec 17, 2015 at 12:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Victor Blomqvist <v...@viblo.se> writes: > >> From time to time I get this and similar errors in my Postgres log file: > > < 2015-12-17 07:45:05.976 CST >ERROR: index > > "user_pictures_picture_dhash_idx" contains unexpected zero page at block > > 123780 > > Hm, can't tell for sure from the error message text, but the index name > suggests that this is a hash index? > > > The server is a read slave, set up with streaming replication. We run > > PostgreSQL 9.3.5. > > Hash indexes are not WAL-logged, which means their contents do not > propagate to slave servers, which basically means you cannot use them > in replication setups. > > > Will it be fixed with a newer version of Postgres? > > Adding WAL-logging to hash indexes has been on the to-do list for a long > time; but it's never gotten done, in part because there has never been > any clear evidence that hash indexes are better than btree indexes for > any real-world purpose. I'm curious why you chose this index type in > the first place. > > regards, tom lane >
