Horton

Re: BUG #18371: There are wrong constraint residues when detach hash partiton concurrently

feichanghong <feichanghong@qq.com>

View thread
From: 费长红 <feichanghong@qq.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>, alvherre <alvherre@alvh.no-ip.org>
Date: 2024-03-05T08:57:18Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Stop creating constraints during DETACH CONCURRENTLY

  2. Rename SLRU elements in view pg_stat_slru

On 2024/3/5, 11:13, "Michael Paquier" <michael@paquier.xyz> wrote:
    Something is weird with the format of the messages you have sent, by
    the way. 

Ah ha! This should be a problem with my email client, I will try another client.

    I am not much a fan of relying on ATExecDropConstraint(), where the
    logic introduced is a copy-paste of get_constraint_name() to retrieve
    the name of the constraint to drop.  If any, we ought to rely more on
    dropconstraint_internal() instead using the pg_constraint tuple based
    on the OID of the constraint, and not do a cross-operation with the
    constraint name.

    But actually, why do you do a drop of the constraint at all?
    DetachAddConstraintIfNeeded() re-adds the constraint as it is, so
    instead of re-adding it as-is and then dropping it again, wouldn't it
    be better to just *not* re-add to begin with it if we don't need it at
    all?

After verification, the partition constraints on the partition being detached
remain in effect until the second transaction committed. This newly added
constraint should only be for the purpose of speeding up the re-attach
operation. Perhaps I've missed something?

So, for hash partitioning, it should be better not to re-add new constraints.
Perhaps we should filter out hash partitions in DetachAddConstraintIfNeeded().

--
Best Regards,
Fei Changhong
Alibaba Cloud Computing Ltd.