Hello!
PART 1:
--------------
Something still wrong with 0006, check:
'pgbench: error: client 12 script 0 aborted in command 2 query 0: ERROR: attempted to overwrite invisible tuple
But it is hard to reproduce - happened once.
--------------
Also, once I got
[16:25:18.641] # at /tmp/cirrus-ci-build/contrib/amcheck/t/
007_repack_concurrently.pl line 57.
[16:25:18.641] # 'pgbench: error: client 6 script 0 aborted in command 2 query 0: ERROR: relation 21856 deleted while still in use
It was the PROC_IN_REPACK version (see below), but I think it is not related to it. But I'm not 100% sure.
PART 2:
> I'm considering a special kind of relation whose catalog entries remain in the
> catalog cache and are never written to the catalog tables. (Unlike temporary
> relation, it'd be WAL logged so that REPACK can be replayed on standby.)
I think it is too complicated, especially including replication logic.
Approach with catalog-only xid is much simpler, it was even committed (yes, reverted but because of another reason).
Essentially we have two issues:
1) make sure catalog entities are not dropped because the vacuum
2) make sure data in new table is not vacuumed also
For the first PROC_IN_REPACK is enough.
For second - depends if MVCC-safe (original xmin/xmax) are preserved. If yes - looks like nothing more needed.
If not - just prevent the vacuum from touching the table (but, looks like it is done already, because lock is held on NewHeap until commit).
And additionally reset snapshots during the index building itself, but it is scope of another patch.
I have implemented PROC_IN_REPACK POC in the attached patch.
Also, I am still not sure if MVCC-safe implementation is worth its complexity compared with "relcheckxmin"approach [0].
Best regards,
Mikhail.
