From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Sergey Burladyan <eshkinkot(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru>, Vladimir Borodin <root(at)simply(dot)name> |
Subject: | Re: Broken hint bits (freeze) |
Date: | 2017-06-30 00:56:34 |
Message-ID: | 20170630005634.GA4448@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 28, 2017 at 10:11:35PM -0400, Bruce Momjian wrote:
> On Fri, Jun 23, 2017 at 06:17:47PM +0300, Sergey Burladyan wrote:
> > PS:
> > I successfully upgraded last night from 9.2 to 9.4 and find other issue :-)
> >
> > It is about hash index and promote:
> > 1. create master
> > 2. create standby from it
> > 3. create unlogged table and hash index like:
> > create unlogged table test (id int primary key, v text);
> > create index on test using hash (id);
> > 3. stop master
> > 4. promote standby
> >
> > now, if you try to upgrade this new promoted master pg_upgrade will stop
> > on this hash index:
> > error while creating link for relation "public.test_id_idx" ("s/9.2/base/16384/16393" to "m/9.4/base/16422/16393"): No such file or directory
> > Failure, exiting
> >
> > I touch this file (s/9.2/base/16384/16393) and rerun pg_upgrade from
> > scratch and it complete successfully.
>
> Sergey, can you please test if the table "test" is not unlogged, does
> pg_upgrade still fail on the hash index file?
I was able to reproduce this failure on my server. :-)
What I found is that the problem is larger than I thought. Sergey is
correct that pg_upgrade fails because there is no hash file associated
with the unlogged table, but in fact a simple access of the unlogged
table with a hash index generates an error:
test=> SELECT * FROM t_u_hash;
ERROR: could not open file "base/16384/16392": No such file or directory
What is interesting is that this is the only combination that generates
an error. A unlogged able with a btree index or a logged table with a
hash index are fine, e.g.:
List of relations
Schema | Name | Type | Owner
--------+-----------+-------+----------
public | t_btree | table | postgres
public | t_hash | table | postgres
public | t_u_btree | table | postgres
fail--> public | t_u_hash | table | postgres
This doesn't fail on PG 10 since we WAL-log hash indexes.
I think we have two questions:
1. do we fix this in the server
2. if not, do we fix pg_upgrade
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2017-06-30 01:31:31 | Re: Apparent walsender bug triggered by logical replication |
Previous Message | Andres Freund | 2017-06-30 00:15:33 | Re: Apparent walsender bug triggered by logical replication |