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
