Re: Preserve attstattarget on REINDEX CONCURRENTLY

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Ronan Dunklau <ronan(at)dunklau(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Preserve attstattarget on REINDEX CONCURRENTLY
Date: 2021-02-04 14:46:50
Message-ID: d4df50ad-fcb0-bc25-d0a4-71e0165b8511@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/4/21 11:04 AM, Ronan Dunklau wrote:
> Hello !
>
> ...
>
> junk=# REINDEX INDEX CONCURRENTLY t1_date_trunc_idx;
> REINDEX
> junk=# \d+ t1_date_trunc_idx
> Index "public.t1_date_trunc_idx"
> Column | Type | Key? | Definition
> | Storage | Stats target
> ------------+-----------------------------+------
> +-----------------------------+---------+--------------
> date_trunc | timestamp without time zone | yes | date_trunc('day'::text, ts)
> | plain |
> btree, for table "public.t1"
>
>
> I'm attaching a patch possibly solving the problem, but maybe the proposed
> changes will be too intrusive ?
>

Hmmm, that sure seems like a bug, or at least unexpected behavior (that
I don't see mentioned in the docs).

But the patch seems borked in some way:

$ patch -p1 < ~/keep_attstattargets_on_reindex_concurrently.patch
patch: **** Only garbage was found in the patch input.

There seem to be strange escape characters and so on, how did you create
the patch? Maybe some syntax coloring, or something?

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ronan Dunklau 2021-02-04 14:52:44 Re: Preserve attstattarget on REINDEX CONCURRENTLY
Previous Message Tom Lane 2021-02-04 14:45:11 Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?