public inbox for [email protected]
help / color / mirror / Atom feedFrom: Mihail Nikalayeu <[email protected]>
To: Antonin Houska <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Mon, 2 Feb 2026 11:04:45 +0100
Message-ID: <CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg@mail.gmail.com> (raw)
In-Reply-To: <8029.1770024929@localhost>
References: <[email protected]>
<11247.1767609087@localhost>
<11558.1767609632@localhost>
<141054.1767891540@localhost>
<CADzfLwU-OmxW3t3AoQo9=K7uq4G1yZ-txcetzW3jbcVxV_pJew@mail.gmail.com>
<137668.1768235610@localhost>
<CADzfLwUJSHKGxYw+vMUZ_Hr2YeuxO2Q5w13HKgUUN1725tjY5Q@mail.gmail.com>
<CADzfLwXJ+4s1tJuG9injcxAUP3urj9D6dUAPOCaX33UeiUxrRQ@mail.gmail.com>
<74802.1769071060@localhost>
<CADzfLwVZ_DeU_3avD=G4ZHFJJgZ0EOFzxnmWxwyB23zsS-uxjA@mail.gmail.com>
<CADzfLwUEH5+LjCN+6kRfSsXwuou8rKXyVV42Wi-O_TG0360Kug@mail.gmail.com>
<3901.1769412880@localhost>
<88003.1769511456@localhost>
<CADzfLwXdaJh4awQstc2PpBz=EBBc6tMA50wYLqMoEtY5B+WUnA@mail.gmail.com>
<57210.1769801636@localhost>
<CADzfLwUukiGOPoUkDgf6oEB-Y0TnNy6UFUN4obnU-AN5W1N=sw@mail.gmail.com>
<8029.1770024929@localhost>
Hello!
> I think it *is* related. My earlier patch version, which used the
> PROC_IN_VACUUM flag improperly [1] was also causing visibility issues.
Please
> let me know if you manage to reproduce the issue with v32.
Will try. Just to highlight - first error happened on v31 *without*
PROC_IN_REPACK.
Second error had PROC_IN_REPACK code, but it wasn't executed (flag wasn't
set) - that's why I think it is not related.
> I'm confused by hearing a complaint about complexity of code that I
haven't
> posted yet. And I don't understand the relationship to "replication
logic":
> REPACK (CONCURRENTLY) tries to avoid decoding of data changes in the *new*
> (transient) relation anyway.
I am not about complexity of code, but more about complexity of approach
(introducing new things like cache-only relations).
"Replication logic" - is about the fact you mentioned that such a relation
is going to be replicated to standby (as result, some replication-related
code is affected too, probably standby promotion also).
Compared to the PROC_IN_REPACK flag - it feels overly complicated for me.
PROC_IN_REPACK is the simplest thing here - just exclude XID from
data-horizon, but keep it in catalog. That's all.
Also, maybe I sound a little bit rude, sorry, it is just because of the
language barrier.
> 3) XID assigned early due to creation of catalog entries for the new
table -
> that XID prevents the VACUUM xmin horizon from advancing till the end of
the
> transaction, i.e. till the end of REPACK execution.
Yes, but PROC_IN_REPACK covers it as well. That xid only in the catalog
horizon.
> IMO it's better for users to see the correct data than ERROR. But it still
> needs work.
Agreed, for me it is ordered like this (from bad to good):
1) silently see incorrect data in rear race
2) receive error instead in that race <----- acceptable for me
3) no error, data is correct
Best regards,
Mikhail.
view thread (31+ 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]
Subject: Re: Adding REPACK [concurrently]
In-Reply-To: <CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg@mail.gmail.com>
* 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