Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Date
Msg-id CAD21AoA3qDyzbiq6+ELT9at=JsW5br5saTHBwY0SCUDS_qfnEQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
List pgsql-hackers
On Mon, Sep 9, 2024 at 4:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
> > When do we set the byte on the primary server? If it's the first time
> > to use the GIN index, secondary servers would have to wait for the
> > primary to use the GIN index, which could be an unpredictable time or
> > it may never come depending on index usages. Probably we can make
> > pg_upgrade set the byte in the meta page of GIN indexes that use the
> > gin_trgm_ops.
>
> Hmm, perhaps.  That plus set-it-during-index-create would remove the
> need for dynamic update like I suggested.  So very roughly the amount
> of complexity would balance out.

Yes, I think your set-it-during-index-create would be necessary.

>  Do you have an idea for how we'd get
> this to happen during pg_upgrade, exactly?

What I was thinking is that we have "pg_dump --binary-upgrade" emit a
function call, say "SELECT binary_upgrade_update_gin_meta_page()" for
each GIN index, and the meta pages are updated when restoring the
schemas.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Disallow altering invalidated replication slots
Next
From: Amit Kapila
Date:
Subject: Re: Disallow altering invalidated replication slots