| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Olivier Macchioni <olivier(dot)macchioni(at)wingo(dot)ch>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
| Date: | 2014-05-15 19:07:14 |
| Message-ID: | 31390.1400180834@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Bruce Momjian <bruce(at)momjian(dot)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 enough to 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-05-15 19:15:31 | Re: BUG #10330: pg_ctl does not correctly honor "DETACHED_PROCESS" |
| Previous Message | Bruce Momjian | 2014-05-15 19:02:35 | Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |