On Wed, Feb 10, 2021 at 12:58:05AM -0600, Justin Pryzby wrote:
> If I'm not wrong, you meant to ORDER BY attrelid::regclass::text, attnum;
Indeed, I meant that. Thanks, Justin!
--
Michael
signature.asc
Description: PGP signature
On Fri, Feb 05, 2021 at 11:17:48AM +0900, Michael Paquier wrote:
> Let's copy this data in index_concurrently_swap() instead. The
> attached patch does that, and adds a test cheaper than what was
> proposed. There is a minor release planned for next week, so I may be
> +++ b/src/test/regress/sql
On Sun, Feb 07, 2021 at 09:39:36AM +0900, Michael Paquier wrote:
> I'll see about applying this stuff after the next version is tagged
> then.
The new versions have been tagged, so done as of bd12080 and
back-patched. I have added a note in the commit log about the
approach to use index_create()
On Sat, Feb 06, 2021 at 10:39:53PM +0100, Tomas Vondra wrote:
> Copying this info in index_concurrently_swap seems a bit strange - we're
> copying other stuff there, but this is modifying something we've already
> copied before. I understand why we do it there to make this backpatchable,
> but mayb
On 2/5/21 8:43 AM, Michael Paquier wrote:
On Fri, Feb 05, 2021 at 08:22:17AM +0100, Ronan Dunklau wrote:
I'm not surprised by this answer, the good news is it's being back-patched.
Yes, I have no problem with that. Until this gets fixed, the damage
can be limited with an extra ALTER INDEX, th
On Fri, Feb 05, 2021 at 08:22:17AM +0100, Ronan Dunklau wrote:
> I'm not surprised by this answer, the good news is it's being back-patched.
Yes, I have no problem with that. Until this gets fixed, the damage
can be limited with an extra ALTER INDEX, that takes a
ShareUpdateExclusiveLock so ther
Le vendredi 5 février 2021, 03:17:48 CET Michael Paquier a écrit :
> ConstructTupleDescriptor() does not matter much, but this patch is not
> acceptable to me as it touches the area of the index creation while
> statistics on an index expression can only be changed with a special
> flavor of ALTER
On Thu, Feb 04, 2021 at 03:52:44PM +0100, Ronan Dunklau wrote:
>> Hmmm, that sure seems like a bug, or at least unexpected behavior (that
>> I don't see mentioned in the docs).
Yeah, per the rule of consistency, this classifies as a bug to me.
> Please find attached a correct patch.
ConstructTup
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
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? | Definit
Hello !
We encountered the following bug recently in production: when running REINDEX
CONCURRENTLY on an index, the attstattarget is reset to 0.
Consider the following example:
junk=# \d+ t1_date_trunc_idx
Index "public.t1_date_trunc_idx"
Column |
11 matches
Mail list logo
