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.
