Re: hash index on unlogged tables doesn't behave as expected

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hash index on unlogged tables doesn't behave as expected
Date: 2017-07-18 06:33:07
Message-ID: CAB7nPqSQDmz+PKewNN9r_7jC4WKf9f31Gkf=DzVGA3q+GsgJEQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 18, 2017 at 4:18 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-07-18 06:38:25 Re: Patch: Add --no-comments to skip COMMENTs with pg_dump
Previous Message Vik Fearing 2017-07-18 06:26:10 Re: New partitioning - some feedback