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.
