Mihail Nikalayeu <mihailnikalayeu@gmail.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
