Re: Adding REPACK [concurrently]

Hello!

> PROC_IN_VACUUM shouldn't be used for the same reason
StartupDecodingContext()
> avoids setting PROC_IN_LOGICAL_DECODING in transaction. I've removed
that and
> the tests work for me. Especially the "cache lookup failed" error is
almost
> certainly related. Please let me know if you still get the other errors

Yes, now it is passing.

> (Except for 2, which is probably due to the MVCC-unsafe behavior, as
discussed
> earlier.)

Not happening too. BTW, it was non MVCC-related, because in that case
relcheckxmin would catch it.

What if:

1) add new PROC_IN_REPACK flag
2) use it in catalog horizon, but not in data (like was done in [0] for
PROC_IN_SAFE_IC)

And after we have options:
3) do not "table_close(NewHeap, NoLock);" -
keep ShareUpdateExclusiveLock all the time to prevent VACUUM enter
4) do not heap_page_prune_opt in repack transaction (just using simple
flag)
Or
3) preserve xmin/xmax of original transaction in repacked data
4) but better to keep ShareUpdateExclusiveLock anyway

Seems to be enough.

> The 0006 part needs more work (definitely beyond PG 19).

This is sad, because if you are in a situation then you need REPACK -
pinning the horizon for too long may just finish your DB....
And also, even with 0006 we still need to build indexes, which might pin it
for long (even duration caused by a single index).

Mikhail.

[0]:
https://github.com/postgres/postgres/commit/d9d076222f5b94a85e0e318339cfc44b8f26022d