From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Victor Blomqvist <vb(at)viblo(dot)se> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Index contains unexpected zero page at block |
Date: | 2015-12-17 04:22:39 |
Message-ID: | 11970.1450326159@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Victor Blomqvist <vb(at)viblo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Victor Blomqvist | 2015-12-17 04:30:18 | Re: Index contains unexpected zero page at block |
Previous Message | Victor Blomqvist | 2015-12-17 03:48:53 | Index contains unexpected zero page at block |