public inbox for [email protected]
help / color / mirror / Atom feedFrom: Antonin Houska <[email protected]>
To: Mihail Nikalayeu <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Mon, 02 Feb 2026 20:39:59 +0100
Message-ID: <58250.1770061199@localhost> (raw)
In-Reply-To: <CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg@mail.gmail.com>
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>
<CADzfLwVf6jB5QBXR3nM838LV6oyqAGJ5b5tXc5aZdovxHPj_kg@mail.gmail.com>
Mihail Nikalayeu <[email protected]> wrote:
> > 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.
ok, v31 is the one that uses PROC_IN_VACUUM incorrectly.
> > 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).
I thought you mean logical replication. Regarding streaming replication, I
mentioned it rather for the record. I need to check details to see if it
requires special attention.
> 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.
My preference is to avoid hacking procarray.c if a reasonable alternative
exists.
> Also, maybe I sound a little bit rude, sorry, it is just because of the language barrier.
No, that's fine. Since we've met at pgconf.eu, I think you're not a bad guy
:-) Technical discussions are mostly about problems, so they tend to sound
negative as such.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
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: <58250.1770061199@localhost>
* 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