Re: [HACKERS] hash index on unlogged tables doesn't behave as expected
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] hash index on unlogged tables doesn't behave as expected |
Дата | |
Msg-id | CAB7nPqSQDmz+PKewNN9r_7jC4WKf9f31Gkf=DzVGA3q+GsgJEQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] hash index on unlogged tables doesn't behave as expected (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] hash index on unlogged tables doesn't behave asexpected
|
Список | pgsql-hackers |
On Tue, Jul 18, 2017 at 4:18 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > Thanks. Do you have any suggestion for back-branches? As of now, it > fails badly with below kind of error: > > test=> SELECT * FROM t_u_hash; > ERROR: could not open file "base/16384/16392": No such file or directory > > It is explained in another thread [3] where it has been found that the > reason for such an error is that hash indexes are not WAL logged prior > to 10. Now, we can claim that we don't recommend hash indexes to be > used prior to 10 in production, so such an error is okay even if there > is no crash has happened in the system. There are a couple of approaches: 1) Marking such indexes as invalid at recovery and log information about the switch done. 2) Error at creation of hash indexes on unlogged tables. 3) Leave it as-is, because there is already a WARNING at creation. I don't mind seeing 3) per the amount of work done lately to support WAL on hash indexes. -- Michael
В списке pgsql-hackers по дате отправления: