But Postgres is not storing this information now anywhere else except statistic, isn't it?
not only - critical numbers are reltuples, relpages from pg_class
That's a very good point. relallvisible too. How's the global temp table impl handling that right now, since you won't be changing the pg_class row? AFAICS relpages doesn't need to be up to date (and reltuples certainly doesn't) so presumably you're just leaving them as zero?
As far as I understand relpages and reltuples are set only when you perform "analyze" of the table.
Also autovacuum's autoanalyze.
What happens right now if you ANALYZE or VACUUM ANALYZE a global temp table? Is it just disallowed?
No, it is not disallowed now. It updates the statistic and also fields in pg_class which are shared by all backends. So all backends will now build plans according to this statistic. Certainly it may lead to not so efficient plans if there are large differences in number of tuples stored in this table in different backends. But seems to me critical mostly in case of presence of indexes for temporary table. And it seems to me that users are created indexes for temporary tables even rarely than doing analyze for them.
That doesn't seem too bad TBH. Hacky but it doesn't seem dangerously wrong and as likely to be helpful as not if clearly documented.
Temporary tables (both local and global) as well as unlogged tables are not subject of logical replication, aren't them?
Right. But in the same way that they're still present in the catalogs, I think they still affect catalog snapshots maintained by logical decoding's historic snapshot manager as temp table creation/drop will still AFAIK cause catalog invalidations to be written on commit. I need to double check that.