Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
От | Tom Lane |
---|---|
Тема | Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
Дата | |
Msg-id | 1361.1400247902@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes (Greg Stark <stark@mit.edu>) |
Ответы |
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 Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
Список | pgsql-bugs |
Greg Stark <stark@mit.edu> writes: > 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. I still think this is throwing the error at the wrong place. People will turn on the GUC the first time it gets in their way, and then much later discover that the index doesn't work on a slave, and we'll get a bug report exactly like this one. We need a check that is tightly connected to actual unsafe usage, rather than basically-user-unfriendly complaints at a point that's not doing anything unsafe. (Well, anything more unsafe than it ever was.) regards, tom lane
В списке pgsql-bugs по дате отправления: