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
>

Reply via email to