Re: Improve behavior of concurrent TRUNCATE

On Mon, Aug 13, 2018 at 01:39:06PM -0400, Robert Haas wrote:
> The original patches would, I think, have been pretty scary to
> back-patch, since the infrastructure didn't exist in older branches
> and we were churning a fairly large amount of code. Now that most
> places are fixed and things have had five years to bake, we could
> conceivably back-patch the remaining fixes. However, I wonder if
> we've really looked into how many instances of this problem remain.
> If there's still ten more that we haven't bothered to fix,
> back-patching one or two that we've gotten around to doing something
> about doesn't make a lot of sense to me.

If we are confident enough to say that all the holes have been patched,
then we could only back-patch down to v11 in my opinion as REINDEX
needed a change of behavior for the handling of shared catalog. FWIW, I
have spent some time fixing all the issues reported on the original
thread, but I did not double-check all commands using an exclusive
lock, hence all the issues I have known of are:
- REINDEX with shared catalogs, fixed by 661dd23.
- TRUNCATE, with something commit only on HEAD with f841ceb2.
- VACUUM FULL, for which I have submitted a patch proposal:
https://www.postgresql.org/message-id/20180812222142.GA6097%40paquier.xyz
--
Michael