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

From: Olivier Macchioni <olivier(dot)macchioni(at)wingo(dot)ch>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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:17:59
Message-ID: 4FB93C6A-2790-4167-931A-E53E6694F73E@wingo.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


On May 15, 2014, at 21:07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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

I am not aware of the technical implementation hurdles, but in this case any of the following behaviors would have been better for me:

- still perform the query, without using the index (preferably issuing a warning of some kind)

- Tom's solution - refuse to perform the query, with a clear error message (looking at the error, I thought I had a broken replication, it's clearly not a nice message to have)

- (possibly replace on-the-fly any hash index by another kind of indexes on the slave when setting up the replication or creating the index on the master? does this even make sense?)

- somehow disallow to setup of streaming replication when there is a hash index in any DB / and refuse the creation of a hash index on a master server, so we don't reach this situation

- I assume there is a usage for hash indexes and we don't simply want to deprecate them

Olivier

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2014-05-15 19:25:33 Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
Previous Message Bruce Momjian 2014-05-15 19:15:31 Re: BUG #10330: pg_ctl does not correctly honor "DETACHED_PROCESS"