Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
Date
Msg-id 31390.1400180834@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes  (Bruce Momjian <bruce@momjian.us>)
Responses Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes  (Olivier Macchioni <olivier.macchioni@wingo.ch>)
Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes  (David G Johnston <david.g.johnston@gmail.com>)
List pgsql-bugs
Bruce Momjian <bruce@momjian.us> writes:
> On Thu, May 15, 2014 at 05:20:35PM +0200, Olivier Macchioni wrote:
>> I guess my best bet is to replace it by another kind of indexes... and maybe one day PostgreSQL will be clever
enoughto issue a warning / error in such a case for the people like me who don't read *all the doc* :P 

> Yes, streaming replication has made our hash indexes even worse.  In the
> past, I have suggested we issue a warning for the creation of hash
> indexes, but did not get enough agreement.

Mainly because it wouldn't be a very helpful message.

I wonder though if we could throw a flat-out error for attempts to use
a hash index on a hot standby server.  That would get people's attention
without being mere nagging in other situations.  It's not a 100% solution
because you'd still lose if you tried to use a hash index on a slave
since promoted to master.  But it would help without being a large
sink for effort.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #10330: pg_ctl does not correctly honor "DETACHED_PROCESS"