Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
От | Greg Stark |
---|---|
Тема | Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
Дата | |
Msg-id | CAM-w4HOAp903Fd_KU9Ur0wmYWncawthGKS4qqHBPmYy5NEJvHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: BUG #10329: Could not read block 0 in file
"base/56100265/57047884": read only 0 of 8192 bytes
Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
Список | pgsql-bugs |
On Thu, May 15, 2014 at 8:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > One of the arguments against Bruce's proposal to print a warning at hash > index creation is that it's a particularly ineffective form of > deprecation. In your example, since the hash index was created by some > app not manually, I'll bet nobody would have seen/noticed the warning > even if there had been one. I suggested we make a GUC allow_unrecoverable_indexes and default it to false. If you want to create hash indexes you need to set it to true or else you just get errors. A more general solution is to emit a WAL record the first time a non-crashsafe index is touched after a checkpoint. On a slave that record could just mark the index invalid. -- greg
В списке pgsql-bugs по дате отправления: