RE: temp table on commit delete rows performance issue

> It seems that in your patch, WAL logging is skipped for all tables, not just
> temporary tables.

This code path is only used in two cases though:
* For the temporary tables ON COMMIT DROP
* For truncating tables that were created in the same transaction, or which
were already truncated in the same transaction (this is some special case
in the TRUNCATE command)
In both cases I believe it's not necessary to log the lock, as the table doesn't exist
on replica yet or the exclusive lock has already been obtained and logged previously.
Regular TRUNCATE commands go through a completely different code path,
as these need to be rollbackable if the transaction aborts.

> Upon further consideration, do we really need to acquire AccessExclusiveLocks
> for temporary tables? Since temporary tables can only be accessed within the
> current session, perhaps we can make the following optimizations:

This one I'm less sure of if it's correct in all cases. Logically it makes sense that no other
backends can access it, however I see some threads [1] that suggest that it's technically
possible for other backends to take locks on these tables, so it's not *that* obvious there
are no edge cases.

[1] https://postgrespro.com/list/thread-id/2477885