public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Masahiko Sawada <[email protected]>
Cc: Noah Misch <[email protected]>
Cc: Joe Conway <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Alexander Korotkov <[email protected]>
Cc: Guo, Adam <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: Jim Mlodgenski <[email protected]>
Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Date: Tue, 10 Sep 2024 02:25:35 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAD21AoA3qDyzbiq6+ELT9at=JsW5br5saTHBwY0SCUDS_qfnEQ@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAD21AoDJEKZO_=szRtOTX6we6wC_wWsHXH1zcEqza2vHE-YW4Q@mail.gmail.com>
<[email protected]>
<CAD21AoBO-iL=UgHKQrKE=7zBrMYR_fAhLb8AGo_kmNgmkPKuQA@mail.gmail.com>
<[email protected]>
<CAD21AoC=7oF29N6iKaTssn-rRGnoTVSLzTQh4ia4ZUO1iKKc_w@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAD21AoCFxA0F+KqsVGLMYME7iW6KdVwvAU9YyieULa92zZx=zg@mail.gmail.com>
<[email protected]>
<CAD21AoA3qDyzbiq6+ELT9at=JsW5br5saTHBwY0SCUDS_qfnEQ@mail.gmail.com>
Masahiko Sawada <[email protected]> writes:
> On Mon, Sep 9, 2024 at 4:42 PM Tom Lane <[email protected]> wrote:
>> 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.
Hmm, but ...
1. IIRC we don't move the relation files into the new cluster until
after we've run the schema dump/restore step. I think this'd have to
be driven in some other way than from the pg_dump output. I guess we
could have pg_upgrade start up the new postmaster and call a function
in each DB, which would have to scan for GIN indexes by itself.
2. How will this interact with --link mode? I don't see how it
doesn't involve scribbling on files that are shared with the old
cluster, leading to possible problems if the pg_upgrade fails later
and the user tries to go back to using the old cluster. It's not so
much the metapage update that is worrisome --- we're assuming that
that will modify storage that's unused in old versions. But the
change would be unrecorded in the old cluster's WAL, which sounds
risky.
Maybe we could get away with forcing --copy mode for affected
indexes, but that feels a bit messy. We'd not want to do it
for unaffected indexes, so the copying code would need to know
a great deal about this problem.
regards, tom lane
view thread (6+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox