Re: Adding REPACK [concurrently]

Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> 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